[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by jason.carver: I'm in Windows XP, using the latest FF35 plugin from trunk and compiling my GWT project against the latest from trunk, but I'm still getting the "No GWT plugin found or hosted-mode connection failed" error. I'm also using -noserver. I am definitely running the hosted-mode server. Any ideas? For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: New API proposal: BatchedCommand
Is there a reason why we just don't add Runnable and Callable to the JRE
emul and use those instead of Command? This design seems to parallel some of
the patterns in ExecutorService. I could see some of those patterns being
useful (like completion queues, which would be useful for staged
animations).
-Ray
On Thu, Sep 3, 2009 at 7:08 PM, Bruce Johnson wrote:
> Okay, here's a strawman for a new-and-improved proposal. All these would be
> in core.
> // "Deferred command" = on the other side of the event loop
> interface DeferredCommands {
> public static DeferredCommands get();
>
> public void add(Command cmd);
> public void add(Command cmd, boolean asap); // asap = faster than
> setTimeout(0)
> public void addPause();
> }
>
> // "Finally command" = before you end the current stack trace
> interface FinallyCommands {
> public static FinallyCommands get();
>
> public void add(Command cmd);
> }
>
> // "Incremental command" = call repeatedly quickly to avoid SSWs
> interface IncrementalCommands {
> public static IncrementalCommands get();
>
> public void add(Command cmd);
> public void add(Command cmd, boolean asap);
> }
>
> // "Timed command" = call based clock time (aka regular old timers)
> interface TimedCommands {
> public static TimedCommand get();
>
> public TimerController scheduleOnce(Command cmd, int millis);
> public TimerController scheduleRecurring(Command cmd, int millis);
> }
>
> // Allows optional control over a timer after it's created.
> // If the return values in scheduleOnce, etc. aren't used, extra code can
> maybe optimize away.
> interface TimerController {
> public void pause();
> public void resume();
> public void cancel();
> }
>
> I think that maybe consolidating timers into this mix might be a bit much,
> but, then again, if we're graduating "Command" to core, then it seems like
> it would be nice to make it the uniform callback interface.
>
> -- Bruce
>
> On Thu, Sep 3, 2009 at 9:28 PM, Bruce Johnson wrote:
>
>> I like it a lot Ray. (To be completely honest, I knew you were going to
>> say all that, so I decided to sandbag and let you do the typing :-)
>>
>> I question if it's really appropriate to explicitly say "PreEventLoop" and
>> "PostEventLoop" considering that...sometimes...the event loop can actually
>> run re-entrantly. Those names sound like a very strong guarantee that I
>> don't think we can reliably guarantee. It's more like
>> "PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
>>
>> Actually, to take a step back (which is my very favorite thing to do),
>> there are several kinds of things that could be consolidated:
>>
>> 1) Single-shot timers
>> 2) Recurring timers
>> 3) Incremental commands that run as soon as possible after the event loop
>> (faster than setTimeout(0))
>> 4) Incremental commands that run after the event loop via setTimeout(0)
>> 5) Deferred commands that run as soon as possible after the event loop
>> (faster than setTimeout(0))
>> 6) Deferred commands that run after the event loop via setTimeout(0)
>> 7) Execute-this-before-you-unwind-the-JS-stack-in-which-it-was-enqueued
>> (aka BatchedCommand)
>> 8) Arguably, runAsync (although it's purpose is so functionally different
>> it would probalby be a mistake to munge it in)
>>
>> #3 and #5 might look funny, but it is generally possible to run code
>> *after* the event loop but *much* sooner than setTimeout(0), which is
>> usually clamped to some pretty long duration such as 10ms. The reason you
>> wouldn't want to do #3 and #5 as the default for deferred commands is that
>> it would keep the CPU overly busy if you did it a bunch in a row. It would
>> very likely drain mobile batteries quickly, even.
>>
>> @Ray (or anyone): Can you think of an awesome way to reconcile those
>> behind a consistent API?
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 3, 2009 at 4:52 PM, Joel Webber wrote:
>>
>>> ++(++Ray)
>>> Anything we can do to sensibly get this crap out of .user and into .core
>>> (or some other common location) would be very, very good.
>>> If, as a side-effect, we could get DeferredCommand to *not* use
>>> IncrementalCommand (the latter brings in fairly significant dependencies
>>> that are enough to matter for small apps), that would be even better.
>>>
>>>
>>> On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum wrote:
>>>
++Ray.
On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan wrote:
> The mechanism is just brilliant. I have reservations about the api.
>
>
> "it seemed kinda nice to have one less type"
>
> Except that we have one more type, BatchedCommand, which looks exactly
> like Command, except with a different name, and you have to subclass it
> rather than implement it...
>
> A simple thing we could do is:
>
>- create com.google.gwt.core.client,
>- change com.google.gwt.user.client.Command to extend the new one
>- deprecate com.google.gwt.user.client.Command
>- And hav
[gwt-contrib] Re: New API proposal: BatchedCommand
Okay, here's a strawman for a new-and-improved proposal. All these would be
in core.
// "Deferred command" = on the other side of the event loop
interface DeferredCommands {
public static DeferredCommands get();
public void add(Command cmd);
public void add(Command cmd, boolean asap); // asap = faster than
setTimeout(0)
public void addPause();
}
// "Finally command" = before you end the current stack trace
interface FinallyCommands {
public static FinallyCommands get();
public void add(Command cmd);
}
// "Incremental command" = call repeatedly quickly to avoid SSWs
interface IncrementalCommands {
public static IncrementalCommands get();
public void add(Command cmd);
public void add(Command cmd, boolean asap);
}
// "Timed command" = call based clock time (aka regular old timers)
interface TimedCommands {
public static TimedCommand get();
public TimerController scheduleOnce(Command cmd, int millis);
public TimerController scheduleRecurring(Command cmd, int millis);
}
// Allows optional control over a timer after it's created.
// If the return values in scheduleOnce, etc. aren't used, extra code can
maybe optimize away.
interface TimerController {
public void pause();
public void resume();
public void cancel();
}
I think that maybe consolidating timers into this mix might be a bit much,
but, then again, if we're graduating "Command" to core, then it seems like
it would be nice to make it the uniform callback interface.
-- Bruce
On Thu, Sep 3, 2009 at 9:28 PM, Bruce Johnson wrote:
> I like it a lot Ray. (To be completely honest, I knew you were going to say
> all that, so I decided to sandbag and let you do the typing :-)
>
> I question if it's really appropriate to explicitly say "PreEventLoop" and
> "PostEventLoop" considering that...sometimes...the event loop can actually
> run re-entrantly. Those names sound like a very strong guarantee that I
> don't think we can reliably guarantee. It's more like
> "PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
>
> Actually, to take a step back (which is my very favorite thing to do),
> there are several kinds of things that could be consolidated:
>
> 1) Single-shot timers
> 2) Recurring timers
> 3) Incremental commands that run as soon as possible after the event loop
> (faster than setTimeout(0))
> 4) Incremental commands that run after the event loop via setTimeout(0)
> 5) Deferred commands that run as soon as possible after the event loop
> (faster than setTimeout(0))
> 6) Deferred commands that run after the event loop via setTimeout(0)
> 7) Execute-this-before-you-unwind-the-JS-stack-in-which-it-was-enqueued
> (aka BatchedCommand)
> 8) Arguably, runAsync (although it's purpose is so functionally different
> it would probalby be a mistake to munge it in)
>
> #3 and #5 might look funny, but it is generally possible to run code
> *after* the event loop but *much* sooner than setTimeout(0), which is
> usually clamped to some pretty long duration such as 10ms. The reason you
> wouldn't want to do #3 and #5 as the default for deferred commands is that
> it would keep the CPU overly busy if you did it a bunch in a row. It would
> very likely drain mobile batteries quickly, even.
>
> @Ray (or anyone): Can you think of an awesome way to reconcile those behind
> a consistent API?
>
>
>
>
>
>
>
> On Thu, Sep 3, 2009 at 4:52 PM, Joel Webber wrote:
>
>> ++(++Ray)
>> Anything we can do to sensibly get this crap out of .user and into .core
>> (or some other common location) would be very, very good.
>> If, as a side-effect, we could get DeferredCommand to *not* use
>> IncrementalCommand (the latter brings in fairly significant dependencies
>> that are enough to matter for small apps), that would be even better.
>>
>>
>> On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum wrote:
>>
>>> ++Ray.
>>>
>>>
>>> On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan wrote:
>>>
The mechanism is just brilliant. I have reservations about the api.
"it seemed kinda nice to have one less type"
Except that we have one more type, BatchedCommand, which looks exactly
like Command, except with a different name, and you have to subclass it
rather than implement it...
A simple thing we could do is:
- create com.google.gwt.core.client,
- change com.google.gwt.user.client.Command to extend the new one
- deprecate com.google.gwt.user.client.Command
- And have BatchedCommand accept com.google.gwt.core.client
And the two names, "DeferredComand" and "BatchedCommand", don't give
much clue as to which does what. And of course BatchedCommand doesn't
actually provide any batching service.
If we were doing all this from scratch, I suspect we would wind up with
something like this in core (presuming we're happy with IncrementalCommand
and addPause):
package com.google.gwt.core.dispatch
public interface Command {
[gwt-contrib] Re: New API proposal: BatchedCommand
I like it a lot Ray. (To be completely honest, I knew you were going to say
all that, so I decided to sandbag and let you do the typing :-)
I question if it's really appropriate to explicitly say "PreEventLoop" and
"PostEventLoop" considering that...sometimes...the event loop can actually
run re-entrantly. Those names sound like a very strong guarantee that I
don't think we can reliably guarantee. It's more like
"PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
Actually, to take a step back (which is my very favorite thing to do), there
are several kinds of things that could be consolidated:
1) Single-shot timers
2) Recurring timers
3) Incremental commands that run as soon as possible after the event loop
(faster than setTimeout(0))
4) Incremental commands that run after the event loop via setTimeout(0)
5) Deferred commands that run as soon as possible after the event loop
(faster than setTimeout(0))
6) Deferred commands that run after the event loop via setTimeout(0)
7) Execute-this-before-you-unwind-the-JS-stack-in-which-it-was-enqueued (aka
BatchedCommand)
8) Arguably, runAsync (although it's purpose is so functionally different it
would probalby be a mistake to munge it in)
#3 and #5 might look funny, but it is generally possible to run code *after*
the event loop but *much* sooner than setTimeout(0), which is usually
clamped to some pretty long duration such as 10ms. The reason you wouldn't
want to do #3 and #5 as the default for deferred commands is that it would
keep the CPU overly busy if you did it a bunch in a row. It would very
likely drain mobile batteries quickly, even.
@Ray (or anyone): Can you think of an awesome way to reconcile those behind
a consistent API?
On Thu, Sep 3, 2009 at 4:52 PM, Joel Webber wrote:
> ++(++Ray)
> Anything we can do to sensibly get this crap out of .user and into .core
> (or some other common location) would be very, very good.
> If, as a side-effect, we could get DeferredCommand to *not* use
> IncrementalCommand (the latter brings in fairly significant dependencies
> that are enough to matter for small apps), that would be even better.
>
>
> On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum wrote:
>
>> ++Ray.
>>
>>
>> On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan wrote:
>>
>>> The mechanism is just brilliant. I have reservations about the api.
>>>
>>>
>>> "it seemed kinda nice to have one less type"
>>>
>>> Except that we have one more type, BatchedCommand, which looks exactly
>>> like Command, except with a different name, and you have to subclass it
>>> rather than implement it...
>>>
>>> A simple thing we could do is:
>>>
>>>- create com.google.gwt.core.client,
>>>- change com.google.gwt.user.client.Command to extend the new one
>>>- deprecate com.google.gwt.user.client.Command
>>>- And have BatchedCommand accept com.google.gwt.core.client
>>>
>>> And the two names, "DeferredComand" and "BatchedCommand", don't give much
>>> clue as to which does what. And of course BatchedCommand doesn't actually
>>> provide any batching service.
>>>
>>> If we were doing all this from scratch, I suspect we would wind up with
>>> something like this in core (presuming we're happy with IncrementalCommand
>>> and addPause):
>>>
>>> package com.google.gwt.core.dispatch
>>>
>>> public interface Command {
>>> void execute();
>>> }
>>>
>>> public interface IncrementalCommand {
>>> boolean execute();
>>> }
>>>
>>> public class PreEventLoopDispatcher {
>>> public static PreEventLoopDispatcher get(); { ... }
>>>
>>> public void addCommand(Command c);
>>> }
>>>
>>> public class PostEventLoopDispatcher {
>>> public static PostEventLoopDispatcher get(); { ... }
>>>
>>> public void addCommand(Command c);
>>> public void addCommand(IncrementalCommand c);
>>> public void addPause();
>>> }
>>>
>>> Note the avoidance of statics to make commands more testable, a recurring
>>> subject.
>>>
>>> Seems like we could do this, deprecate the existing classes, and make
>>> them wrappers around the new.
>>>
>>>
>>>
>>> On Wed, Sep 2, 2009 at 11:36 PM, Ray Cromwell wrote:
>>>
Could this also be used as a general pattern to batch DOM updates from
multiple Widgets performing updates? e.g. a current approach to avoid the
overhead, of say, installing a dozen widgets, is to concatenate all the
HTML
together, slam it into innerHTML, and then wrap the widgets around the
HTML.
But this rather breaks the nice OO design people are used to with widgets.
Templating is an alternative, but I'm wondering, why can't we make all of
the attachment stuff happen via a batch queue. A special optimizer on the
queue could even recognize instances of when DOM updates can be coalesced
and leverage documentFragment or innerHTML.
e.g.
VerticalPanel vp = ...
vp.add(new Label())
vp.add(new Label())
The objects are constr
[gwt-contrib] [google-web-toolkit] r6088 committed - Edited wiki page through web user interface.
Revision: 6088 Author: tamplinjohn Date: Thu Sep 3 16:19:08 2009 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=6088 Modified: /wiki/UsingOOPHM.wiki === --- /wiki/UsingOOPHM.wiki Thu Sep 3 15:40:15 2009 +++ /wiki/UsingOOPHM.wiki Thu Sep 3 16:19:08 2009 @@ -27,8 +27,8 @@ If you are running multiple versions of Firefox, it is recommended to use different profiles for each version. - * *Safari 3/4 on MacOSX* - Run the installer from this [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/webkit/prebuilt/oophm.dmg disk image]. + * *Safari 3/4 on MacOSX (PPC/x86)* + Run the installer from this [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/webkit/prebuilt/oophm.dmg disk image]. Note that x86_64 is not yet supported, which means Safari on Snow Leopard is not yet supported. * *IE6/7/8* Download [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/ie/prebuilt/oophm.dll oophm.dll] to local disk. Run regsvr32 oophm.dll and restart IE. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Hello ui:style
Committed r6087 http://gwt-code-reviews.appspot.com/64801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6086 committed - Edited wiki page through web user interface.
Revision: 6086 Author: tamplinjohn Date: Thu Sep 3 15:40:15 2009 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=6086 Modified: /wiki/UsingOOPHM.wiki === --- /wiki/UsingOOPHM.wiki Wed Aug 5 12:08:38 2009 +++ /wiki/UsingOOPHM.wiki Thu Sep 3 15:40:15 2009 @@ -12,19 +12,26 @@ The solution is to invert the problem -- instead of embedding the browser in hosted mode, we will embed a hosted mode plugin in the browser. This has a much smaller footprint that is easier to support, and then we can get support for multiple browsers per platform and cross-machine hosted mode (ie, running hosted mode on Linux and connecting to it from IE on a Windows machine). = Installing the Plugin = + You will need to install a plugin in each browser you intend to use with OOPHM. * *Google Chrome* Not yet, sorry. - * *Firefox 3 (not 3.5 yet)* - Install the [http://google-web-toolkit.googlecode.com/svn/branches/oophm/plugins/xpcom/prebuilt/oophm-xpcom.xpi plugin] in your browser. + * *Firefox* + _*Note: If you have previously installed an OOPHM plugin, you will need to uninstall or disable it first.*_ + Install the appropriate XPI by clicking below while running Firefox: +* [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/gwt-dmp-ff2.xpi Firefox 2] (Mac PPC/x86, Linux x86/x86_64) +* [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/gwt-dmp-ff3.xpi Firefox 3] (Win x86, Mac PPC/x86, Linux x86/x86_64) +* [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/gwt-dmp-ff35.xpi Firefox 3.5] (Win x86, Mac PPC/x86, Linux x86/x86_64) + + If you are running multiple versions of Firefox, it is recommended to use different profiles for each version. * *Safari 3/4 on MacOSX* - Run the installer from this [http://google-web-toolkit.googlecode.com/svn/branches/oophm/plugins/webkit/prebuilt/oophm.dmg disk image]. + Run the installer from this [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/webkit/prebuilt/oophm.dmg disk image]. * *IE6/7/8* - Download [http://google-web-toolkit.googlecode.com/svn/branches/oophm/plugins/ie/prebuilt/oophm.dll oophm.dll] to local disk. Run regsvr32 oophm.dll and restart IE. + Download [http://google-web-toolkit.googlecode.com/svn/trunk/plugins/ie/prebuilt/oophm.dll oophm.dll] to local disk. Run regsvr32 oophm.dll and restart IE. = Using OOPHM = OOPHM is currently in trunk (it is not and will not be available with 1.6 or earlier versions), but is not enabled by default because the UI needs some work and some features are missing, plus it just hasn't had enough testing to be sure it is completely usable as a replacement. So, to use it now, you need to add gwt-dev-oophm.jar at the beginning of your classpath. There are a number of ways to do it: --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6084 committed - Missing paren in debug message.
Revision: 6084
Author: j...@google.com
Date: Thu Sep 3 14:56:24 2009
Log: Missing paren in debug message.
http://code.google.com/p/google-web-toolkit/source/detail?r=6084
Modified:
/changes/jat/plugins/plugins/common/AllowedConnections.cpp
===
--- /changes/jat/plugins/plugins/common/AllowedConnections.cpp Sun Aug 30
08:28:05 2009
+++ /changes/jat/plugins/plugins/common/AllowedConnections.cpp Thu Sep 3
14:56:24 2009
@@ -85,7 +85,7 @@
void AllowedConnections::addRule(const std::string& pattern,
bool exclude) {
Debug::log(Debug::Spam) << "AllowedConnections::addRule(pattern=" <<
pattern
- << ", excl=" << exclude << Debug::flush;
+ << ", excl=" << exclude << ")" << Debug::flush;
rules.push_back(AllowedConnections::Rule(pattern, exclude));
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Hello ui:style
Thanks. Updated with some checkstyle fixes. Running tests, should submit soon. http://gwt-code-reviews.appspot.com/64801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6083 committed - Checkstyle fixes for DockLayoutPanel. Whoops.
Revision: 6083
Author: j...@google.com
Date: Thu Sep 3 14:07:51 2009
Log: Checkstyle fixes for DockLayoutPanel. Whoops.
http://code.google.com/p/google-web-toolkit/source/detail?r=6083
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
===
--- /trunk/user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java Thu
Sep 3 12:28:14 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java Thu
Sep 3 14:07:51 2009
@@ -61,6 +61,9 @@
NORTH, EAST, SOUTH, WEST, CENTER, LINE_START, LINE_END
}
+ /**
+ * Layout data associated with each widget.
+ */
protected static class LayoutData {
public Direction direction;
public double oldSize, size;
@@ -105,6 +108,28 @@
public void add(Widget widget, Direction direction, double size) {
insert(widget, direction, size, null);
}
+
+ /**
+ * TODO(jgw): Is this really the best way to do this?
+ */
+ public Element getContainerElementFor(Widget widget) {
+assertIsChild(widget);
+return
((LayoutData)widget.getLayoutData()).layer.getContainerElement();
+ }
+
+ /**
+ * Gets the layout direction of the given child widget.
+ *
+ * @param w the widget to be queried
+ * @return the widget's layout direction, or null if it is
not a
+ * child of this panel
+ */
+ public Direction getWidgetDirection(Widget w) {
+if (w.getParent() != this) {
+ return null;
+}
+return ((LayoutData) w.getLayoutData()).direction;
+ }
/**
* Adds a widget to the specified edge of the dock. If the widget is
already a
@@ -148,62 +173,6 @@
// Adopt.
adopt(widget);
}
-
- /**
- * Gets the layout direction of the given child widget.
- *
- * @param w the widget to be queried
- * @return the widget's layout direction, or null if it is
not a
- * child of this panel
- */
- public Direction getWidgetDirection(Widget w) {
-if (w.getParent() != this) {
- return null;
-}
-return ((LayoutData) w.getLayoutData()).direction;
- }
-
- public void onResize() {
-for (Widget child : getChildren()) {
- if (child instanceof RequiresResize) {
-((RequiresResize) child).onResize();
- }
-}
- }
-
- @Override
- public boolean remove(Widget w) {
-boolean removed = super.remove(w);
-if (removed) {
- // Clear the center widget.
- if (w == center) {
-center = null;
- }
-
- LayoutData data = (LayoutData) w.getLayoutData();
- layout.removeChild(data.layer);
-}
-
-return removed;
- }
-
- protected Widget getCenter() {
-return center;
- }
-
- protected Unit getUnit() {
-return unit;
- }
-
- @Override
- protected void onLoad() {
-layout.onAttach();
- }
-
- @Override
- protected void onUnload() {
-layout.onDetach();
- }
public void layout() {
layout(0);
@@ -282,12 +251,46 @@
});
}
- /**
- * TODO(jgw): Is this really the best way to do this?
- */
- public Element getContainerElementFor(Widget widget) {
-assertIsChild(widget);
-return
((LayoutData)widget.getLayoutData()).layer.getContainerElement();
+ public void onResize() {
+for (Widget child : getChildren()) {
+ if (child instanceof RequiresResize) {
+((RequiresResize) child).onResize();
+ }
+}
+ }
+
+ @Override
+ public boolean remove(Widget w) {
+boolean removed = super.remove(w);
+if (removed) {
+ // Clear the center widget.
+ if (w == center) {
+center = null;
+ }
+
+ LayoutData data = (LayoutData) w.getLayoutData();
+ layout.removeChild(data.layer);
+}
+
+return removed;
+ }
+
+ protected Widget getCenter() {
+return center;
+ }
+
+ protected Unit getUnit() {
+return unit;
+ }
+
+ @Override
+ protected void onLoad() {
+layout.onAttach();
+ }
+
+ @Override
+ protected void onUnload() {
+layout.onDetach();
}
private void assertIsChild(Widget widget) {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6082 committed - Add a dialog to let the user allow/deny connections.
Revision: 6082
Author: j...@google.com
Date: Thu Sep 3 14:01:13 2009
Log: Add a dialog to let the user allow/deny connections.
http://code.google.com/p/google-web-toolkit/source/detail?r=6082
Added:
/changes/jat/plugins/plugins/ie/oophm/oophm/AllowDialog.cpp
/changes/jat/plugins/plugins/ie/oophm/oophm/AllowDialog.h
/changes/jat/plugins/plugins/ie/oophm/oophm/resource.h
Deleted:
/changes/jat/plugins/plugins/ie/oophm/oophm/Resource.h
Modified:
/changes/jat/plugins/plugins/ie/oophm/oophm/Preferences.cpp
/changes/jat/plugins/plugins/ie/oophm/oophm/dllmain.cpp
/changes/jat/plugins/plugins/ie/oophm/oophm/oophm.aps
/changes/jat/plugins/plugins/ie/oophm/oophm/oophm.rc
/changes/jat/plugins/plugins/ie/oophm/oophm/oophm.vcproj
/changes/jat/plugins/plugins/ie/oophm/oophm/plugin.cpp
/changes/jat/plugins/plugins/ie/prebuilt/oophm.dll
===
--- /dev/null
+++ /changes/jat/plugins/plugins/ie/oophm/oophm/AllowDialog.cpp Thu Sep 3
14:01:13 2009
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+
+#include "AllowDialog.h"
+#include "Debug.h"
+#include "resource.h"
+
+HINSTANCE AllowDialog::hInstance;
+
+static BOOL CALLBACK allowDialogProc(HWND hwndDlg, UINT message, WPARAM
wParam, LPARAM lParam) {
+ if (message != WM_COMMAND) {
+return false;
+ }
+ bool allowed;
+ switch (LOWORD(wParam)) {
+case IDCANCEL:
+ allowed = false;
+ break;
+case IDC_ALLOW_BUTTON:
+ allowed = true;
+ break;
+default:
+ // ignore anything but buttons which close the dialog
+ return false;
+ }
+ bool remember = IsDlgButtonChecked(hwndDlg, IDC_REMEMBER_CHECKBOX) ==
BST_CHECKED;
+ int returnVal = (allowed ? 1 : 0) + (remember ? 2 : 0);
+ EndDialog(hwndDlg, (INT_PTR) returnVal);
+ return true;
+}
+
+void AllowDialog::setHInstance(HINSTANCE hInstance) {
+ AllowDialog::hInstance = hInstance;
+}
+
+bool AllowDialog::askUserToAllow(bool* remember) {
+ int result = (int) DialogBox(hInstance,
MAKEINTRESOURCE(IDD_ALLOW_DIALOG),
+ NULL, (DLGPROC) allowDialogProc);
+ *remember = (result & 2) != 0;
+ return (result & 1) != 0;
+}
===
--- /dev/null
+++ /changes/jat/plugins/plugins/ie/oophm/oophm/AllowDialog.h Thu Sep 3
14:01:13 2009
@@ -0,0 +1,38 @@
+#ifndef _H_AllowDialog
+#define _H_AllowDialog
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+
+#include "stdafx.h"
+
+class AllowDialog {
+public:
+ static void setHInstance(HINSTANCE hInstance);
+
+ /**
+ * Ask the user if a connection should be allowed.
+ *
+ * @param remember *remember is set to true if the user asked us to
remember this decision,
+ * false otherwise
+ * @return return true if this connection should be allowed
+ */
+ static bool askUserToAllow(bool* remember);
+
+private:
+ static HINSTANCE hInstance;
+};
+
+#endif
===
--- /dev/null
+++ /changes/jat/plugins/plugins/ie/oophm/oophm/resource.h Thu Sep 3
14:01:13 2009
@@ -0,0 +1,24 @@
+//{{NO_DEPENDENCIES}}
+// Microsoft Visual C++ generated include file.
+// Used by oophm.rc
+//
+#define IDS_PROJNAME100
+#define IDR_OOPHM 101
+#define IDR_PLUGIN 103
+#define IDD_ALLOW_DIALOG103
+#define IDH_PLUGIN 103
+#define IDR_JAVAOBJECT 105
+#define IDR_EXCEPTIONCATCHER106
+#define IDC_REMEMBER_CHECKBOX 201
+#define IDC_ALLOW_BUTTON202
+
+// Next default values for new objects
+//
+#ifdef APSTUDIO_INVOKED
+#ifndef APSTUDIO_READONLY_SYMBOLS
+#define _APS_NEXT_RESOURCE_VALUE202
+#define _APS_NEXT_COMMAND_VALUE 32768
+#define _APS_NEXT_CONTROL_VALUE 204
+#define _APS_NEXT_SYMED_VALUE 107
+#endif
+#endif
===
[gwt-contrib] Re: New API proposal: BatchedCommand
++(++Ray)
Anything we can do to sensibly get this crap out of .user and into .core (or
some other common location) would be very, very good.
If, as a side-effect, we could get DeferredCommand to *not* use
IncrementalCommand (the latter brings in fairly significant dependencies
that are enough to matter for small apps), that would be even better.
On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum wrote:
> ++Ray.
>
>
> On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan wrote:
>
>> The mechanism is just brilliant. I have reservations about the api.
>>
>>
>> "it seemed kinda nice to have one less type"
>>
>> Except that we have one more type, BatchedCommand, which looks exactly
>> like Command, except with a different name, and you have to subclass it
>> rather than implement it...
>>
>> A simple thing we could do is:
>>
>>- create com.google.gwt.core.client,
>>- change com.google.gwt.user.client.Command to extend the new one
>>- deprecate com.google.gwt.user.client.Command
>>- And have BatchedCommand accept com.google.gwt.core.client
>>
>> And the two names, "DeferredComand" and "BatchedCommand", don't give much
>> clue as to which does what. And of course BatchedCommand doesn't actually
>> provide any batching service.
>>
>> If we were doing all this from scratch, I suspect we would wind up with
>> something like this in core (presuming we're happy with IncrementalCommand
>> and addPause):
>>
>> package com.google.gwt.core.dispatch
>>
>> public interface Command {
>> void execute();
>> }
>>
>> public interface IncrementalCommand {
>> boolean execute();
>> }
>>
>> public class PreEventLoopDispatcher {
>> public static PreEventLoopDispatcher get(); { ... }
>>
>> public void addCommand(Command c);
>> }
>>
>> public class PostEventLoopDispatcher {
>> public static PostEventLoopDispatcher get(); { ... }
>>
>> public void addCommand(Command c);
>> public void addCommand(IncrementalCommand c);
>> public void addPause();
>> }
>>
>> Note the avoidance of statics to make commands more testable, a recurring
>> subject.
>>
>> Seems like we could do this, deprecate the existing classes, and make them
>> wrappers around the new.
>>
>>
>>
>> On Wed, Sep 2, 2009 at 11:36 PM, Ray Cromwell wrote:
>>
>>>
>>> Could this also be used as a general pattern to batch DOM updates from
>>> multiple Widgets performing updates? e.g. a current approach to avoid the
>>> overhead, of say, installing a dozen widgets, is to concatenate all the HTML
>>> together, slam it into innerHTML, and then wrap the widgets around the HTML.
>>> But this rather breaks the nice OO design people are used to with widgets.
>>> Templating is an alternative, but I'm wondering, why can't we make all of
>>> the attachment stuff happen via a batch queue. A special optimizer on the
>>> queue could even recognize instances of when DOM updates can be coalesced
>>> and leverage documentFragment or innerHTML.
>>> e.g.
>>>
>>> VerticalPanel vp = ...
>>> vp.add(new Label())
>>> vp.add(new Label())
>>>
>>> The objects are constructed, but the HTML mutations are deferred/queued.
>>> When adding a DOM mutation to the queue, you could check if existing queue
>>> data isOrHasChild the new DOM mutation element, and if so, just modify the
>>> queue element (coalesce) rather than appending another queue item. Then,
>>> when processing the queue, you only need to add the roots to the DOM,
>>> attaching/modifying enmasse.
>>>
>>> This would preserve the OO-ness of constructing widget hierarchies
>>> without requiring 'foreign' string-based templating.
>>>
>>> -Ray
>>>
>>>
>>> On Wed, Sep 2, 2009 at 5:13 PM, Bruce Johnson wrote:
>>>
On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum wrote:
> I do agree with John that we should really discuss how this can be
> implemented.
It's already implemented!
> Is there some magic trick to make the browser execute a piece of code
> at the time you want, or do we need to go and modify all our event code
> (like with the global uncaught exception handler)?
No trick, it's as bad as you'd hope it wasn't. On the positive side,
it's already been done -- I'm just augmenting the tests for the various
subsystems such as RequestBuilder and event dispatching to make sure we
tighten the correctness noose as much as possible.
Longer term, Bob and I both would really like to find a general
mechanism for making this pattern easy to do from any path into a GWT
module
from "the outside", exactly along the lines of what Matt was talking about.
I think rolling this functionality into gwt-exporter (and then rolling that
sort of functionality directly into GWT proper) will get us pretty far down
the road.
Code review request forthcoming, possibly tomorrow.
-- Bruce
>>>
>>
>>
>>
>
> >
>
--~--~-~--~~--
[gwt-contrib] htmlunit 2.6 is out
And there are quite a few fixes in it, in case anyone wants to update the lib. http://htmlunit.sourceforge.net/changes-report.html#a2.6 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: New API proposal: BatchedCommand
++Ray.
On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan wrote:
> The mechanism is just brilliant. I have reservations about the api.
>
>
> "it seemed kinda nice to have one less type"
>
> Except that we have one more type, BatchedCommand, which looks exactly like
> Command, except with a different name, and you have to subclass it rather
> than implement it...
>
> A simple thing we could do is:
>
>- create com.google.gwt.core.client,
>- change com.google.gwt.user.client.Command to extend the new one
>- deprecate com.google.gwt.user.client.Command
>- And have BatchedCommand accept com.google.gwt.core.client
>
> And the two names, "DeferredComand" and "BatchedCommand", don't give much
> clue as to which does what. And of course BatchedCommand doesn't actually
> provide any batching service.
>
> If we were doing all this from scratch, I suspect we would wind up with
> something like this in core (presuming we're happy with IncrementalCommand
> and addPause):
>
> package com.google.gwt.core.dispatch
>
> public interface Command {
> void execute();
> }
>
> public interface IncrementalCommand {
> boolean execute();
> }
>
> public class PreEventLoopDispatcher {
> public static PreEventLoopDispatcher get(); { ... }
>
> public void addCommand(Command c);
> }
>
> public class PostEventLoopDispatcher {
> public static PostEventLoopDispatcher get(); { ... }
>
> public void addCommand(Command c);
> public void addCommand(IncrementalCommand c);
> public void addPause();
> }
>
> Note the avoidance of statics to make commands more testable, a recurring
> subject.
>
> Seems like we could do this, deprecate the existing classes, and make them
> wrappers around the new.
>
>
>
> On Wed, Sep 2, 2009 at 11:36 PM, Ray Cromwell wrote:
>
>>
>> Could this also be used as a general pattern to batch DOM updates from
>> multiple Widgets performing updates? e.g. a current approach to avoid the
>> overhead, of say, installing a dozen widgets, is to concatenate all the HTML
>> together, slam it into innerHTML, and then wrap the widgets around the HTML.
>> But this rather breaks the nice OO design people are used to with widgets.
>> Templating is an alternative, but I'm wondering, why can't we make all of
>> the attachment stuff happen via a batch queue. A special optimizer on the
>> queue could even recognize instances of when DOM updates can be coalesced
>> and leverage documentFragment or innerHTML.
>> e.g.
>>
>> VerticalPanel vp = ...
>> vp.add(new Label())
>> vp.add(new Label())
>>
>> The objects are constructed, but the HTML mutations are deferred/queued.
>> When adding a DOM mutation to the queue, you could check if existing queue
>> data isOrHasChild the new DOM mutation element, and if so, just modify the
>> queue element (coalesce) rather than appending another queue item. Then,
>> when processing the queue, you only need to add the roots to the DOM,
>> attaching/modifying enmasse.
>>
>> This would preserve the OO-ness of constructing widget hierarchies without
>> requiring 'foreign' string-based templating.
>>
>> -Ray
>>
>>
>> On Wed, Sep 2, 2009 at 5:13 PM, Bruce Johnson wrote:
>>
>>> On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum wrote:
>>>
I do agree with John that we should really discuss how this can be
implemented.
>>>
>>>
>>> It's already implemented!
>>>
>>>
Is there some magic trick to make the browser execute a piece of code
at the time you want, or do we need to go and modify all our event code
(like with the global uncaught exception handler)?
>>>
>>>
>>> No trick, it's as bad as you'd hope it wasn't. On the positive side, it's
>>> already been done -- I'm just augmenting the tests for the various
>>> subsystems such as RequestBuilder and event dispatching to make sure we
>>> tighten the correctness noose as much as possible.
>>>
>>> Longer term, Bob and I both would really like to find a general mechanism
>>> for making this pattern easy to do from any path into a GWT module from "the
>>> outside", exactly along the lines of what Matt was talking about. I think
>>> rolling this functionality into gwt-exporter (and then rolling that sort of
>>> functionality directly into GWT proper) will get us pretty far down the
>>> road.
>>>
>>> Code review request forthcoming, possibly tomorrow.
>>>
>>> -- Bruce
>>>
>>>
>>>
>>
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Issue 4010: clean up DOMImplTrident. getTagName()
committed as r6081 http://gwt-code-reviews.appspot.com/59805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6081 committed - Fixes a bug in DOMImplTrident#getTagName() where it does not handle an...
Revision: 6081
Author: jlaba...@google.com
Date: Thu Sep 3 13:43:19 2009
Log: Fixes a bug in DOMImplTrident#getTagName() where it does not handle an
undefined scope name.
Patch by: kerjin2001
Review by: jlabanca
http://code.google.com/p/google-web-toolkit/source/detail?r=6081
Modified:
/trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.java
===
--- /trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.java Wed Sep
2 07:58:52 2009
+++ /trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.java Thu Sep
3 13:43:19 2009
@@ -203,8 +203,7 @@
String tagName = getTagNameInternal(elem);
String scopeName = getScopeNameInternal(elem);
-if ("html".equalsIgnoreCase(scopeName)
-|| "undefined".equalsIgnoreCase(scopeName)) {
+if ((scopeName == null) || "html".equalsIgnoreCase(scopeName)) {
return tagName;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: New API proposal: BatchedCommand
The mechanism is just brilliant. I have reservations about the api.
"it seemed kinda nice to have one less type"
Except that we have one more type, BatchedCommand, which looks exactly like
Command, except with a different name, and you have to subclass it rather
than implement it...
A simple thing we could do is:
- create com.google.gwt.core.client,
- change com.google.gwt.user.client.Command to extend the new one
- deprecate com.google.gwt.user.client.Command
- And have BatchedCommand accept com.google.gwt.core.client
And the two names, "DeferredComand" and "BatchedCommand", don't give much
clue as to which does what. And of course BatchedCommand doesn't actually
provide any batching service.
If we were doing all this from scratch, I suspect we would wind up with
something like this in core (presuming we're happy with IncrementalCommand
and addPause):
package com.google.gwt.core.dispatch
public interface Command {
void execute();
}
public interface IncrementalCommand {
boolean execute();
}
public class PreEventLoopDispatcher {
public static PreEventLoopDispatcher get(); { ... }
public void addCommand(Command c);
}
public class PostEventLoopDispatcher {
public static PostEventLoopDispatcher get(); { ... }
public void addCommand(Command c);
public void addCommand(IncrementalCommand c);
public void addPause();
}
Note the avoidance of statics to make commands more testable, a recurring
subject.
Seems like we could do this, deprecate the existing classes, and make them
wrappers around the new.
On Wed, Sep 2, 2009 at 11:36 PM, Ray Cromwell wrote:
>
> Could this also be used as a general pattern to batch DOM updates from
> multiple Widgets performing updates? e.g. a current approach to avoid the
> overhead, of say, installing a dozen widgets, is to concatenate all the HTML
> together, slam it into innerHTML, and then wrap the widgets around the HTML.
> But this rather breaks the nice OO design people are used to with widgets.
> Templating is an alternative, but I'm wondering, why can't we make all of
> the attachment stuff happen via a batch queue. A special optimizer on the
> queue could even recognize instances of when DOM updates can be coalesced
> and leverage documentFragment or innerHTML.
> e.g.
>
> VerticalPanel vp = ...
> vp.add(new Label())
> vp.add(new Label())
>
> The objects are constructed, but the HTML mutations are deferred/queued.
> When adding a DOM mutation to the queue, you could check if existing queue
> data isOrHasChild the new DOM mutation element, and if so, just modify the
> queue element (coalesce) rather than appending another queue item. Then,
> when processing the queue, you only need to add the roots to the DOM,
> attaching/modifying enmasse.
>
> This would preserve the OO-ness of constructing widget hierarchies without
> requiring 'foreign' string-based templating.
>
> -Ray
>
>
> On Wed, Sep 2, 2009 at 5:13 PM, Bruce Johnson wrote:
>
>> On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum wrote:
>>
>>> I do agree with John that we should really discuss how this can be
>>> implemented.
>>
>>
>> It's already implemented!
>>
>>
>>> Is there some magic trick to make the browser execute a piece of code at
>>> the time you want, or do we need to go and modify all our event code (like
>>> with the global uncaught exception handler)?
>>
>>
>> No trick, it's as bad as you'd hope it wasn't. On the positive side, it's
>> already been done -- I'm just augmenting the tests for the various
>> subsystems such as RequestBuilder and event dispatching to make sure we
>> tighten the correctness noose as much as possible.
>>
>> Longer term, Bob and I both would really like to find a general mechanism
>> for making this pattern easy to do from any path into a GWT module from "the
>> outside", exactly along the lines of what Matt was talking about. I think
>> rolling this functionality into gwt-exporter (and then rolling that sort of
>> functionality directly into GWT proper) will get us pretty far down the
>> road.
>>
>> Code review request forthcoming, possibly tomorrow.
>>
>> -- Bruce
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
Yes, this is definitely going to be a part of the 2.0 release. Which is why I am glad to have all the feedback I can get :) On Thu, Sep 3, 2009 at 4:10 PM, Sami Jaber wrote: > No pb Joel, now that I better understand the kind of issue you faced, let's > say ok to this naming scheme. > If I seem to insist it's because this initial design will drive the > implementation of all the remaining panels (and the tons of third-party > toolkits) > Once all those panels will be developed on top of this new API, going > backward will be difficult (like the event model in fact...). > btw do you know if this new layout model is aimed at being part of the > initial release of GWT 2.0 ? > > Sami > > On Thu, Sep 3, 2009 at 9:30 PM, wrote: > >> >> On 2009/09/03 17:50:24, jgw wrote: >> >> >> Committed at r6080. >> @Sami: Note that this is not set in stone yet -- let's continue the >> discussion about those interfaces in the meantime. >> >> http://gwt-code-reviews.appspot.com/63801 >> >> >> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
No pb Joel, now that I better understand the kind of issue you faced, let's say ok to this naming scheme. If I seem to insist it's because this initial design will drive the implementation of all the remaining panels (and the tons of third-party toolkits) Once all those panels will be developed on top of this new API, going backward will be difficult (like the event model in fact...). btw do you know if this new layout model is aimed at being part of the initial release of GWT 2.0 ? Sami On Thu, Sep 3, 2009 at 9:30 PM, wrote: > > On 2009/09/03 17:50:24, jgw wrote: > > > Committed at r6080. > @Sami: Note that this is not set in stone yet -- let's continue the > discussion about those interfaces in the meantime. > > http://gwt-code-reviews.appspot.com/63801 > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
Doing it all platforms style. I also confirmed that this does the right thing on Leopard when you run both the 1.5 and 1.6 vms. http://gwt-code-reviews.appspot.com/64805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Fix for issue 3528
On 2009/08/26 15:21:26, t.broyer wrote: Just so you know, I haven't forgotten about this, but I'm really swamped this week. I'm out next week, but will have a look at this as soon as I get back (unless someone else beats me to it). http://gwt-code-reviews.appspot.com/61813 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Removing HistoryImplIE6 refresh timer.
It looks like there's enough pushback on this that we may want to drop it for now and have someone look into why at least one internal app is having bizarre refresh problems. Mothballing this patch for now. On Thu, Sep 3, 2009 at 11:24 AM, John Tamplin wrote: > On Thu, Sep 3, 2009 at 11:12 AM, wrote: > >> What conditions trigger this? >> >> Also, is it possible that somebody is relying on this. For example, what >> happens if you use a link to change the hash from outside a GWT app, >> assuming that the GWT app will catch it? >> > > I don't use IE except when testing, but I do have multiple bookmarks saved > within the same GWT app. I don't know that I ever use the bookmark to move > between history states rather than just selecting it in the app, but I could > imagine if the app was really large and complicated that I might. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6080 committed - - Changed Requires/ProvidesLayout => Requires/ProvidesResize; some sma...
Revision: 6080
Author: j...@google.com
Date: Thu Sep 3 12:28:14 2009
Log: - Changed Requires/ProvidesLayout => Requires/ProvidesResize; some
small doc
additions.
- Added RequiresLayout; moved doc into it.
- Added LayoutPanelExample.
- Added DockLayoutPanel.
- A bit of cleanup here and there.
Review: http://gwt-code-reviews.appspot.com/63801
http://code.google.com/p/google-web-toolkit/source/detail?r=6080
Added:
/trunk/user/javadoc/com/google/gwt/examples/DockLayoutPanelExample.java
/trunk/user/javadoc/com/google/gwt/examples/LayoutExample.java
/trunk/user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
/trunk/user/src/com/google/gwt/user/client/ui/ProvidesResize.java
/trunk/user/src/com/google/gwt/user/client/ui/RequiresResize.java
Deleted:
/trunk/user/src/com/google/gwt/layout/client/UserAgent.java
/trunk/user/src/com/google/gwt/user/client/ui/ProvidesLayout.java
Modified:
/trunk/user/javadoc/com/google/gwt/examples/LayoutPanelExample.java
/trunk/user/src/com/google/gwt/layout/client/Layout.java
/trunk/user/src/com/google/gwt/layout/client/LayoutImpl.java
/trunk/user/src/com/google/gwt/layout/client/LayoutImplIE6.java
/trunk/user/src/com/google/gwt/user/client/ui/LayoutComposite.java
/trunk/user/src/com/google/gwt/user/client/ui/LayoutPanel.java
/trunk/user/src/com/google/gwt/user/client/ui/RequiresLayout.java
/trunk/user/src/com/google/gwt/user/client/ui/RootLayoutPanel.java
===
--- /dev/null
+++ /trunk/user/javadoc/com/google/gwt/examples/DockLayoutPanelExample.java
Thu Sep 3 12:28:14 2009
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.examples;
+
+import com.google.gwt.core.client.EntryPoint;
+import com.google.gwt.dom.client.Style.Unit;
+import com.google.gwt.user.client.ui.DockLayoutPanel;
+import com.google.gwt.user.client.ui.HTML;
+import com.google.gwt.user.client.ui.RootLayoutPanel;
+import com.google.gwt.user.client.ui.DockLayoutPanel.Direction;
+
+public class DockLayoutPanelExample implements EntryPoint {
+
+ public void onModuleLoad() {
+// Attach five widgets to a DockLayoutPanel, one in each direction. Lay
+// them out in 'em' units.
+DockLayoutPanel p = new DockLayoutPanel(Unit.EM);
+p.add(new HTML("north"), Direction.NORTH, 2);
+p.add(new HTML("south"), Direction.SOUTH, 2);
+p.add(new HTML("east"), Direction.EAST, 2);
+p.add(new HTML("west"), Direction.WEST, 2);
+p.add(new HTML("center"), Direction.CENTER, 2);
+
+// Note the explicit call to layout(). This is required for the layout
to
+// take effect.
+p.layout();
+
+// Attach the LayoutPanel to the RootLayoutPanel. The latter will
listen for
+// resize events on the window to ensure that its children are
informed of
+// possible size changes.
+RootLayoutPanel rp = RootLayoutPanel.get();
+rp.add(p);
+
+// The RootLayoutPanel also requires that its layout() method be
explicitly
+// called for the initial layout to take effect.
+rp.layout();
+ }
+}
===
--- /dev/null
+++ /trunk/user/javadoc/com/google/gwt/examples/LayoutExample.java Thu Sep
3 12:28:14 2009
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.examples;
+
+import static com.google.gwt.dom.client.Style.Unit.EM;
+import static com.google.gwt.dom.client.Style.Unit.PCT;
+import static com.google.gwt.dom.client.Style.Unit.PX;
+
+import com.google.gwt.core.client.EntryPoint;
+import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.Element;
+import com.google.gwt.layout.client.Layout;
+import com.google.gwt.layout.client.Layout.Layer;
+
+public class LayoutExample implements EntryPoint {
+
+ public void onModuleLoad() {
+// The following is a very simple e
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
If you are on IntelliJ IDEA, I'm not sure about Eclipse. OSX has this app called "Java Preferences.app" that changes the system /usr/bin/java so that it points to which VM you want, so when you type "java -version" from the command line, you'll get the appropriate VM. That is, if you select 32-bit, it will have -d32 added implicitly. However, IntelliJ doesn't launch the VM via symbolic links in the path, it goes directly to /System/Library/Frameworks/JavaVM.Framework, so you must add -d32 as a VM parameter in the launch config. One other effect of -d32 is that it appears to force the client VM, whereas -d64 is the server VM. -Ray On Thu, Sep 3, 2009 at 12:25 PM, Rajeev Dayal wrote: > @Ray: To clarify, you need to add -d32 to the launch config though, right? > > > On Thu, Sep 3, 2009 at 3:22 PM, wrote: > >> >> On 2009/09/03 19:07:53, knorton wrote: >> > Ray, >> >> > Can you confirm that this patch fixes the Snow Leopard issue. It's the >> same >> > patch as before with the typo fixed and the error message slightly >> expanded. >> >> Works on Snow Leopard with IntelliJ as launcher against GWT 2.0 trunk. >> LGTM. >> >> http://gwt-code-reviews.appspot.com/64805 >> >> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
I can't say it'll work everywhere, but it's in the official Sun Hotspot FAQ: http://www.j2ee.me/docs/hotspot/HotSpotFAQ.html#64bit_detection On 2009/09/03 19:21:06, knorton wrote: > Sure, does sun.arch.data.model work everywhere? > /kel > On 2009/09/03 19:17:16, jat wrote: > > On 2009/09/03 19:07:53, knorton wrote: > > > Ray, > > > > > > Can you confirm that this patch fixes the Snow Leopard issue. It's the same > > > patch as before with the typo fixed and the error message slightly expanded. > > > > Since we have the 32-bit issue on other platforms, should we do this in common > > code instead? http://gwt-code-reviews.appspot.com/64805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
Sure, does sun.arch.data.model work everywhere? /kel On 2009/09/03 19:17:16, jat wrote: > On 2009/09/03 19:07:53, knorton wrote: > > Ray, > > > > Can you confirm that this patch fixes the Snow Leopard issue. It's the same > > patch as before with the typo fixed and the error message slightly expanded. > Since we have the 32-bit issue on other platforms, should we do this in common > code instead? http://gwt-code-reviews.appspot.com/64805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
@Ray: To clarify, you need to add -d32 to the launch config though, right? On Thu, Sep 3, 2009 at 3:22 PM, wrote: > > On 2009/09/03 19:07:53, knorton wrote: > > Ray, > > > Can you confirm that this patch fixes the Snow Leopard issue. It's the > same > > patch as before with the typo fixed and the error message slightly > expanded. > > Works on Snow Leopard with IntelliJ as launcher against GWT 2.0 trunk. > LGTM. > > http://gwt-code-reviews.appspot.com/64805 > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
On 2009/09/03 17:50:24, jgw wrote: Committed at r6080. @Sami: Note that this is not set in stone yet -- let's continue the discussion about those interfaces in the meantime. http://gwt-code-reviews.appspot.com/63801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
In the rare cases it fails, the user will just get what they get by default now. Seems like we should go ahead and do it for all the platforms. I'll add the checking to HostedModeBase, but have it call back into BootStrapPlatform for the error message so we can keep the OS X specific hints. http://gwt-code-reviews.appspot.com/64805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6079 committed - giving gwt.junit a haltonfailure attribute....
Revision: 6079 Author: fabb...@google.com Date: Thu Sep 3 12:14:51 2009 Log: giving gwt.junit a haltonfailure attribute. Review by: jlabanca http://code.google.com/p/google-web-toolkit/source/detail?r=6079 Modified: /trunk/common.ant.xml === --- /trunk/common.ant.xml Mon Aug 24 10:44:29 2009 +++ /trunk/common.ant.xml Thu Sep 3 12:14:51 2009 @@ -178,6 +178,7 @@ + @@ -245,7 +246,13 @@ - + + + + + + + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
On 2009/09/03 19:07:53, knorton wrote: > Ray, > Can you confirm that this patch fixes the Snow Leopard issue. It's the same > patch as before with the typo fixed and the error message slightly expanded. Works on Snow Leopard with IntelliJ as launcher against GWT 2.0 trunk. LGTM. http://gwt-code-reviews.appspot.com/64805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)
On 2009/09/03 19:07:53, knorton wrote: > Ray, > Can you confirm that this patch fixes the Snow Leopard issue. It's the same > patch as before with the typo fixed and the error message slightly expanded. Since we have the 32-bit issue on other platforms, should we do this in common code instead? http://gwt-code-reviews.appspot.com/64805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Snow Leopard 32-bit checking fix (1.7 based)
Reviewers: cromwellian,
Message:
Ray,
Can you confirm that this patch fixes the Snow Leopard issue. It's the
same patch as before with the typo fixed and the error message slightly
expanded.
Please review this at http://gwt-code-reviews.appspot.com/64805
Affected files:
M dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java
Index: dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java
diff --git a/dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java
b/dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java
index
164a4a6afbda075cb2c71695ee1b72f99f26c65d..e1c70573fec7098757477143e7087b0a23068080
100644
--- a/dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java
+++ b/dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java
@@ -69,8 +69,10 @@ public class BootStrapPlatform {
* The following check must be made before attempting to initialize
Safari,
* or we'll fail with an less-than-helpful UnsatisfiedLinkError.
*/
-if (!isJava5()) {
- System.err.println("You must use a Java 1.5 runtime to use GWT
Hosted Mode on Mac OS X.");
+if (!is32Bit()) {
+ System.err.println("You must use a 32-bit runtime to use GWT Hosted
Mode on Mac OS X.");
+ System.err.println(" Leopard: Use the Java 1.5 runtime.");
+ System.err.println(" Snow Leopard: Use the Java 1.6 runtime and add
-d32");
System.exit(-1);
}
@@ -111,11 +113,10 @@ public class BootStrapPlatform {
}
/**
- * Determine if we're using the Java 1.5 runtime, since the 1.6 runtime
is
- * 64-bit.
+ * Determine if we're using a 32 bit runtime.
*/
- private static boolean isJava5() {
-return System.getProperty("java.version").startsWith("1.5");
+ private static boolean is32Bit() {
+return "32".equals(System.getProperty("sun.arch.data.model"));
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Hello ui:style
I've updated the patch to snip the strays and to check for CssResource ancestry. On Thu, Sep 3, 2009 at 10:40 AM, wrote: > On 2009/09/03 04:05:36, Ray Ryan wrote: > >> Okay, name -> field was trivial, done. >> > > LGTM so far. I modified a bit of the mail sample to use this, and it > worked a charm. > > A couple of minor nits: > - I assume that DS_Store and ButtonTest are accidentally attached to > this patch. > - Could use some validation on Style interface not extending > CssResource. I failed to do this on my first try, and the error is > pretty deeply obscure, because it's not caught until the compiler sees > it. Don't consider this blocking, though -- just something we should do > before shipping. > > > > http://gwt-code-reviews.appspot.com/64801 > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Hello ui:style
On 2009/09/03 17:40:20, jgw wrote: > On 2009/09/03 04:05:36, Ray Ryan wrote: > > Okay, name -> field was trivial, done. > LGTM so far. I modified a bit of the mail sample to use this, and it worked a > charm. > A couple of minor nits: > - I assume that DS_Store and ButtonTest are accidentally attached to this patch. > - Could use some validation on Style interface not extending CssResource. I > failed to do this on my first try, and the error is pretty deeply obscure, > because it's not caught until the compiler sees it. Don't consider this > blocking, though -- just something we should do before shipping. LGTM. http://gwt-code-reviews.appspot.com/64801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Remove HtmlUnit from 'ant test' and update a couple of tests
LGTM http://gwt-code-reviews.appspot.com/64804 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6078 committed - Removing HtmlUnit from ant test target until the tests are more reliab...
Revision: 6078
Author: jlaba...@google.com
Date: Thu Sep 3 10:59:12 2009
Log: Removing HtmlUnit from ant test target until the tests are more
reliable. Also fixed a checkstyle error and a minor bug in a couple of
tests.
Patch by: jlabanca
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=6078
Modified:
/trunk/user/build.xml
/trunk/user/test/com/google/gwt/resources/client/TextResourceTest.java
/trunk/user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
===
--- /trunk/user/build.xml Tue Aug 11 12:50:31 2009
+++ /trunk/user/build.xml Thu Sep 3 10:59:12 2009
@@ -219,7 +219,6 @@
-
===
--- /trunk/user/test/com/google/gwt/resources/client/TextResourceTest.java
Wed Jun 17 12:42:19 2009
+++ /trunk/user/test/com/google/gwt/resources/client/TextResourceTest.java
Thu Sep 3 10:59:12 2009
@@ -61,8 +61,8 @@
}
};
-r.helloWorldExternal().getText(c);
delayTestFinish(2000);
+r.helloWorldExternal().getText(c);
}
public void testInline() {
===
---
/trunk/user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
Tue Sep 1 11:53:48 2009
+++
/trunk/user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
Thu Sep 3 10:59:12 2009
@@ -17,6 +17,9 @@
import junit.framework.TestCase;
+/**
+ * Tests for {...@link FieldReferenceConverter}.
+ */
public class FieldReferenceConverterTest extends TestCase {
FieldReferenceConverter.Delegate provider = new
FieldReferenceConverter.Delegate() {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
http://gwt-code-reviews.appspot.com/63801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Remove HtmlUnit from 'ant test' and update a couple of tests
Reviewers: fabbott,
Description:
This patch removes HtmlUnit from the main 'ant test' call until we can
hash out the failures in our build. It also adds a comment to a test to
fix a checkstyle error, and it moves a delayTestFinish() call to avoid
sporadic failures that have occurred on the build system.
Please review this at http://gwt-code-reviews.appspot.com/64804
Affected files:
user/build.xml
user/test/com/google/gwt/resources/client/TextResourceTest.java
user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
Index:
user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
===
---
user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
(revision 6077)
+++
user/test/com/google/gwt/uibinder/parsers/FieldReferenceConverterTest.java
(working copy)
@@ -17,6 +17,9 @@
import junit.framework.TestCase;
+/**
+ * Tests for {...@link FieldReferenceConverter}.
+ */
public class FieldReferenceConverterTest extends TestCase {
FieldReferenceConverter.Delegate provider = new
FieldReferenceConverter.Delegate() {
Index: user/test/com/google/gwt/resources/client/TextResourceTest.java
===
--- user/test/com/google/gwt/resources/client/TextResourceTest.java
(revision 6077)
+++ user/test/com/google/gwt/resources/client/TextResourceTest.java
(working copy)
@@ -61,8 +61,8 @@
}
};
+delayTestFinish(2000);
r.helloWorldExternal().getText(c);
-delayTestFinish(2000);
}
public void testInline() {
Index: user/build.xml
===
--- user/build.xml (revision 6077)
+++ user/build.xml (working copy)
@@ -219,7 +219,6 @@
-
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Hello ui:style
On 2009/09/03 04:05:36, Ray Ryan wrote: > Okay, name -> field was trivial, done. LGTM so far. I modified a bit of the mail sample to use this, and it worked a charm. A couple of minor nits: - I assume that DS_Store and ButtonTest are accidentally attached to this patch. - Could use some validation on Style interface not extending CssResource. I failed to do this on my first try, and the error is pretty deeply obscure, because it's not caught until the compiler sees it. Don't consider this blocking, though -- just something we should do before shipping. http://gwt-code-reviews.appspot.com/64801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Focus/blur on a group of widgets?
Oooh, sorry. You were asking the *hard* question, not the easy one. I think the short answer is that there's no easy answer. See http://code.google.com/p/google-web-toolkit/issues/detail?id=1431 for some of the reasons. Another short answer is "I don't get this stuff but Joel does." rjrjr On Wed, Sep 2, 2009 at 12:13 PM, Ed wrote: > > Tanks Ray, > > I understand what you mean but don't really see how this could solve > my problem. > > My problem is to detect a single focus/blur event of a group of > widgets. > > Looking at your explanation I do translate these events to a general > ValidationChange event. > However, to trigger the validation of my composite widget I have to > detect a single blur (like explained above of the examples). > Reading your explanation; my problem is the implementation of this > semantic event as the client won't see this blur/focus event directly, > but the ValidationChangeEvent. > > Is there anyway to "analyze" the upcomming gwt events, when receiving > a gwt event? In this way I can see if a focus event of one of the > widgets in the group is following the blur event, so I can decide if > the blur event is a blur of the whole group of widgets > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Eliminate dead links in SOYC dashboard when displayDependencies is off
Reviewers: Lex,
Description:
Hi Lex,
could you review this patch for me? It eliminates some dead links in
the dashboard when displayDependencies is turned off.
Thanks!
kathrin
Please review this at http://gwt-code-reviews.appspot.com/65803
Affected files:
dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
Index: dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
===
--- dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
(revision
6077)
+++ dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
(working
copy)
@@ -729,7 +729,7 @@
outFile.println("");
outFile.println("" + size + "");
outFile.println("" + perc + "%");
-if (dependencyLink != null) {
+if ((settings.displayDependencies) && (dependencyLink != null)) {
outFile.println("" + className + "");
} else {
@@ -1007,15 +1007,17 @@
private void addLefttoversStatus(String className, String packageName,
PrintWriter out, String permutationId) {
-out.println("See why it's live");
-for (int sp = 1; sp <= globalInformation.getNumSplitPoints(); sp++) {
+if (settings.displayDependencies) {
out.println("See why it's not exclusive to s.p. #" + sp + "
("
- + globalInformation.getSplitPointToLocation().get(sp)
- + ")");
+ + dependenciesFileName("total", packageName, permutationId) + "#"
+ + className + "\">See why it's live");
+ for (int sp = 1; sp <= globalInformation.getNumSplitPoints(); sp++) {
+out.println("See why it's not exclusive to s.p. #" + sp
+ " ("
++ globalInformation.getSplitPointToLocation().get(sp)
++ ")");
+ }
}
}
@@ -1386,9 +1388,14 @@
out.println("");
if
(globalInformation.getInitialCodeBreakdown().classToSize.containsKey(className))
{
- out.println("Some code is initial (see why)");
+ if (settings.displayDependencies) {
+out.println("Some code is initial (see why)");
+ }
+ else {
+out.println("Some code is initial");
+ }
}
for (int sp : splitPointsWithClass(className)) {
out.println("Some code downloads with s.p. #" + sp + " ("
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Change SOYC dashboard to accept symbol maps created by different linker
Reviewers: Lex, schuck_google.com,
Description:
This change to the dashboard updates the settings parser to read symbol
maps files created with the CompactSymbolLinker.
Please review this at http://gwt-code-reviews.appspot.com/65802
Affected files:
dev/core/src/com/google/gwt/soyc/Settings.java
Index: dev/core/src/com/google/gwt/soyc/Settings.java
===
--- dev/core/src/com/google/gwt/soyc/Settings.java (revision 6077)
+++ dev/core/src/com/google/gwt/soyc/Settings.java (working copy)
@@ -230,16 +230,19 @@
while ((sc.hasNextLine()) && (lineCount < 2)) {
String curLine = sc.nextLine();
- curLine = curLine.replace("# {", "");
- curLine = curLine.replace("}", "");
curLine = curLine.trim();
- if (lineCount == 0) {
-permutationId = curLine;
- } else {
-permutationInfo = curLine;
+ if (curLine.startsWith("# {")) {
+curLine = curLine.replace("# {", "");
+curLine = curLine.replace("}", "");
+curLine = curLine.trim();
+if (lineCount == 0) {
+ permutationId = curLine;
+} else {
+ permutationInfo = curLine;
+}
+lineCount++;
}
- lineCount++;
}
allPermsInfo.put(permutationId, permutationInfo);
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: give gwt.junit a haltonfailure attribute
LGTM Thanks, John LaBanca jlaba...@google.com On Thu, Sep 3, 2009 at 11:47 AM, Freeland Abbott wrote: > Looks like we want a different solution for test.web.htmlunit, but here's > the haltonfailure flag for gwt.junit --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] give gwt.junit a haltonfailure attribute
Looks like we want a different solution for test.web.htmlunit, but here's the haltonfailure flag for gwt.junit --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- gwtjunit-haltonfailure.patch Description: Binary data
[gwt-contrib] Re: Removing HistoryImplIE6 refresh timer.
On Thu, Sep 3, 2009 at 11:12 AM, wrote: > What conditions trigger this? > > Also, is it possible that somebody is relying on this. For example, what > happens if you use a link to change the hash from outside a GWT app, > assuming that the GWT app will catch it? > I don't use IE except when testing, but I do have multiple bookmarks saved within the same GWT app. I don't know that I ever use the bookmark to move between history states rather than just selecting it in the app, but I could imagine if the app was really large and complicated that I might. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Removing HistoryImplIE6 refresh timer.
What conditions trigger this? Also, is it possible that somebody is relying on this. For example, what happens if you use a link to change the hash from outside a GWT app, assuming that the GWT app will catch it? http://gwt-code-reviews.appspot.com/64803 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
On 2009/09/02, Sami Jaber wrote:
> Just a few remarks relating to the design changes...
> RequiresLayout.java : We expose now animation routines in this
interface. With
> those new animation methods this interface becomes more constraining
when you
> have to provide a subclass. What about a panel provider that would not
want to
> implement any animation stuff ? Maybe something like
> RequiresLayoutWithAnimation and RequiresLayoutWithoutAnimation or
design
> something that would lead to optional animation would be nice.
> LayoutPanel.java : ProvidesLayout is replaced by both interfaces
RequiresResize
> and ProvidesResize. IMHO this split seems to be redundant. Why this
separation
> if at the end onLayout() calls onResize() and onResize() calls
onResize() for
> all its children?
> ProvidesLayout.java: This class is removed and replaced by
ProvideResize but in
> the providers side, we have two different interfaces RequiresLayout
and
> RequiresResize...
> Joel, would be very interested to understand the limitations you got
in the
> previous design.
I probably should have explained this in more detail in the initial
change description. In the original design, we had {Requires,
Provides}Layout interfaces. These have simply been renamed to {Requires,
Provides}Resize. The reason is that the word "layout" had been badly
overloaded to mean both "realize any pending changes to this panel's
layout, possibly animating" and "notify this widget that its size may
have changed". The former is, IMHO, closer to the dictionary meaning of
"layout", while the latter is closer to the standard IE event "onresize"
(if only every browser had implemented that incredibly useful event, we
wouldn't even have to discuss this!).
As for the new version of RequiresLayout, I'm actually somewhat
ambivalent about this as an interface. Originally, they (layout(),
layout(int), and layout(int, callback)) were just instance methods on
individual panels, but they ended up being the same on LayoutPanel,
DockLayoutPanel, StackLayoutPanel, etc, and I really didn't want to
document them in 3+ different places. It was also nice to be able to say
"if this widget implements RequiresLayout, then you *must* call layout()
to realize any pending changes" in one place.
I wouldn't object to having RequiresLayout just contain the layout()
method, possibly moving the others to another interface (again, to avoid
the multiple-javadoc problem). Anyone have any thoughts on this
(preferably with an idea for what this interface should be called)?
http://gwt-code-reviews.appspot.com/63801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
http://gwt-code-reviews.appspot.com/63801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
http://gwt-code-reviews.appspot.com/63801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
http://gwt-code-reviews.appspot.com/63801/diff/1/2
File user/javadoc/com/google/gwt/examples/DockLayoutPanelExample.java
(right):
http://gwt-code-reviews.appspot.com/63801/diff/1/2#newcode49
Line 49: rp.layout();
On 2009/09/03 04:34:04, Ray Ryan wrote:
> So this doesn't call its children's layout methods? That seems like a
shame. If
> it does, then the p.layout method above is redundant, right?
It does not. See comments below about RequiresLayout for a deeper
discussion.
http://gwt-code-reviews.appspot.com/63801/diff/1/3
File user/javadoc/com/google/gwt/examples/LayoutExample.java (right):
http://gwt-code-reviews.appspot.com/63801/diff/1/3#newcode35
Line 35: // percentages.
On 2009/09/03 04:34:04, Ray Ryan wrote:
> Might as well make this the class comment.
These samples get slurped up in generated doc without the enclosing
class, so I have to keep the comments internal.
> Worth mentioning that most app developers won't do this (right?), and
what
> they'd do instead.
This will only ever be seen as part of the Layout class' doc, which
itself points out that you probably don't want to use this directly.
http://gwt-code-reviews.appspot.com/63801/diff/1/3#newcode43
Line 43: Element topChild = doc.createDivElement(), bottomChild =
doc.createDivElement();
On 2009/09/03 04:34:04, Ray Ryan wrote:
> long line
Done.
http://gwt-code-reviews.appspot.com/63801/diff/1/8
File user/src/com/google/gwt/layout/client/UserAgent.java (right):
http://gwt-code-reviews.appspot.com/63801/diff/1/8#newcode24
Line 24: public class UserAgent {
On 2009/09/03 04:34:04, Ray Ryan wrote:
> should file an issue to make sure you remember to hit this TODO before
2.0 ships
> (or make this not public again), or we'll be living with this for a
long time...
This shouldn't have been here in the first place. BobV's come up with a
"soft permutations" system that will make this a lot simpler and more
sensible. For the time being, I've simplified and hoisted this code into
LayoutImplIE6 and made it private.
http://gwt-code-reviews.appspot.com/63801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Removing HistoryImplIE6 refresh timer.
Reviewers: jlabanca,
Please review this at http://gwt-code-reviews.appspot.com/64803
Affected files:
M user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
Index: user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
diff --git a/user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
b/user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
index
0d73ba5afcb1e9d33db50a1b0e96bfd9f05b22a8..532cdd11a0e95e122bc91dfde38aa7cd8b5fbb94
100644
--- a/user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
+++ b/user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
@@ -85,7 +85,6 @@ class HistoryImplIE6 extends HistoryImpl {
}
injectGlobalHandler();
-initUrlCheckTimer();
return true;
}
@@ -140,43 +139,6 @@ class HistoryImplIE6 extends HistoryImpl {
@com.google.gwt.user.client.impl.HistoryImpl::setToken(Ljava/lang/String;)(token);
}-*/;
- private native void initUrlCheckTimer() /*-{
-// This is the URL check timer. It detects when an unexpected change
-// occurs in the document's URL (e.g. when the user enters one manually
-// or selects a 'favorite', but only the #hash part changes). When
this
-// occurs, we _must_ reload the page. This is because IE has a really
-// nasty bug that totally mangles its history stack and causes the
location
-// bar in the UI to stop working under these circumstances.
-var historyImplRef = this;
-var urlChecker = function() {
- $wnd.setTimeout(urlChecker, 250);
-
- // Reset the hash if the user cancels a window reload triggered by
the
- // urlChecker.
- if
(historyimplr...@com.google.gwt.user.client.impl.historyimplie6::handleWindowReloadCanceled()())
{
-return;
- }
-
- var hash =
@com.google.gwt.user.client.impl.HistoryImplIE6::getLocationHash()();
- if (hash.length > 0) {
-var token = '';
-try {
- token =
historyimplr...@com.google.gwt.user.client.impl.historyimpl::decodeFragment(Ljava/lang/String;)(hash.substring(1));
-} catch (e) {
- // If there's a bad hash, always reload. This could only happen
if
- // if someone entered or linked to a bad url.
-
historyimplr...@com.google.gwt.user.client.impl.historyimplie6::reloadWindow()();
-}
-
-var historyToken =
@com.google.gwt.user.client.impl.HistoryImpl::getToken()();
-if (historyToken && (token != historyToken)) {
-
historyimplr...@com.google.gwt.user.client.impl.historyimplie6::reloadWindow()();
-}
- }
-};
-urlChecker();
- }-*/;
-
private native void injectGlobalHandler() /*-{
var historyImplRef = this;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: r6073 committed - Removing an assertion that introduced a breaking change....
LGTM. I have no objection to loosening up these assertions when a case like this comes up. Others (e.g., input type='password') may have to be loosened up at some point as well. On Thu, Sep 3, 2009 at 3:01 AM, Thomas Broyer wrote: > > > On 2 sep, 19:56, codesite-nore...@google.com wrote: > > Revision: 6073 > > Author: jlaba...@google.com > > Date: Wed Sep 2 10:55:41 2009 > > Log: Removing an assertion that introduced a breaking change. > > > > Patch by: jlabanca > > Review by: jgw (TBR) > > > > http://code.google.com/p/google-web-toolkit/source/detail?r=6073 > > > > Modified: > > /trunk/user/src/com/google/gwt/user/client/ui/Button.java > > > > === > > --- /trunk/user/src/com/google/gwt/user/client/ui/Button.java Wed Sep > 2 > > 07:58:52 2009 > > +++ /trunk/user/src/com/google/gwt/user/client/ui/Button.java Wed Sep > 2 > > 10:55:41 2009 > > @@ -54,7 +54,6 @@ > > assert Document.get().getBody().isOrHasChild(element); > > > > Button button = new Button(element); > > -assert > "button".equalsIgnoreCase(button.getButtonElement().getType()); > > > > // Mark it attached and remember it for cleanup. > > button.onAttach(); > > As I said when posting the initial patch, that was something I > was"unsure about" (and I explicitly pointed out that it was breaking > backwards compat') http://gwt-code-reviews.appspot.com/61809 > > ...but on the other hand, TextBox.wrap() has an assertion on type=text > (actually in the TextBox(Element) ctor) which makes it unable to wrap > an (use a PasswordTextBox for that) whereas > PasswordTextBox doesn't add any particular method or behavior change > to TextBox. This is a very similar situation to Button vs. > SubmitButton and ResetButton. > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
Hello Everyone, I am interested in contributing to this project. However, I will not be able to do coding as I do not have the time for committing to such an activity. I can give my thoughts, analysis/design and testing if needed. Please let me know if my help is needed. Regards, Jitesh Dundas On 9/3/09, j...@google.com wrote: > > > Reviewers: Ray Ryan, > > > > Please review this at http://gwt-code-reviews.appspot.com/63801 > > Affected files: > A user/javadoc/com/google/gwt/examples/DockLayoutPanelExample.java > A user/javadoc/com/google/gwt/examples/LayoutExample.java > M user/javadoc/com/google/gwt/examples/LayoutPanelExample.java > M user/src/com/google/gwt/layout/client/Layout.java > M user/src/com/google/gwt/layout/client/LayoutImpl.java > M user/src/com/google/gwt/layout/client/LayoutImplIE6.java > M user/src/com/google/gwt/layout/client/UserAgent.java > A user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java > M user/src/com/google/gwt/user/client/ui/LayoutComposite.java > M user/src/com/google/gwt/user/client/ui/LayoutPanel.java > M user/src/com/google/gwt/user/client/ui/ProvidesLayout.java > A user/src/com/google/gwt/user/client/ui/ProvidesResize.java > M user/src/com/google/gwt/user/client/ui/RequiresLayout.java > A user/src/com/google/gwt/user/client/ui/RequiresResize.java > M user/src/com/google/gwt/user/client/ui/RootLayoutPanel.java > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A number of layout-related changes.
Just a few remarks relating to the design changes...
*RequiresLayout.java* : We expose now animation routines in this interface.
With those new animation methods this interface becomes more constraining
when you have to provide a subclass. What about a panel provider that would
not want to implement any animation stuff ? Maybe something like
RequiresLayoutWithAnimation and RequiresLayoutWithoutAnimation or design
something that would lead to optional animation would be nice.
*LayoutPanel.java* : ProvidesLayout is replaced by both interfaces
RequiresResize and ProvidesResize. IMHO this split seems to be redundant.
Why this separation if at the end onLayout() calls onResize() and onResize()
calls onResize() for all its children ?
*ProvidesLayout.java:* This class is removed and replaced by ProvideResize
but in the providers side, we have two different interfaces RequiresLayout
and RequiresResize ...
Joel, would be very interested to understand the limitations you got in the
previous design ….
Sami
On Thu, Sep 3, 2009 at 6:34 AM, wrote:
>
> Still LGTM, some nits.
>
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/2
> File user/javadoc/com/google/gwt/examples/DockLayoutPanelExample.java
> (right):
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/2#newcode49
> Line 49: rp.layout();
> So this doesn't call its children's layout methods? That seems like a
> shame. If it does, then the p.layout method above is redundant, right?
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/3
> File user/javadoc/com/google/gwt/examples/LayoutExample.java (right):
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/3#newcode35
> Line 35: // percentages.
> Might as well make this the class comment.
>
> Worth mentioning that most app developers won't do this (right?), and
> what they'd do instead.
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/3#newcode43
> Line 43: Element topChild = doc.createDivElement(), bottomChild =
> doc.createDivElement();
> long line
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/8
> File user/src/com/google/gwt/layout/client/UserAgent.java (right):
>
> http://gwt-code-reviews.appspot.com/63801/diff/1/8#newcode24
> Line 24: public class UserAgent {
> should file an issue to make sure you remember to hit this TODO before
> 2.0 ships (or make this not public again), or we'll be living with this
> for a long time...
>
> http://gwt-code-reviews.appspot.com/63801
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Issue 4010: clean up DOMImplTrident. getTagName()
LGTM I'll submit this later http://gwt-code-reviews.appspot.com/59805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Issue 4010: clean up DOMImplTrident. getTagName()
Later meaning within the next day http://gwt-code-reviews.appspot.com/59805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Snow Leopard 32-bit checking fix.
http://gwt-code-reviews.appspot.com/64802/diff/1/2
File dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java (right):
http://gwt-code-reviews.appspot.com/64802/diff/1/2#newcode117
Line 117: return "32".equals(System.getProperty("sun.arg.data.model"));
On 2009/09/03 05:56:42, jat wrote:
> If this is cross-platform, shouldn't we do this check for all
platforms when not
> using OOPHM?
Typo:
sun.arch.data.model, not sun.arg.data.model
http://gwt-code-reviews.appspot.com/64802
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: r6073 committed - Removing an assertion that introduced a breaking change....
On 2 sep, 19:56, codesite-nore...@google.com wrote: > Revision: 6073 > Author: jlaba...@google.com > Date: Wed Sep 2 10:55:41 2009 > Log: Removing an assertion that introduced a breaking change. > > Patch by: jlabanca > Review by: jgw (TBR) > > http://code.google.com/p/google-web-toolkit/source/detail?r=6073 > > Modified: > /trunk/user/src/com/google/gwt/user/client/ui/Button.java > > === > --- /trunk/user/src/com/google/gwt/user/client/ui/Button.java Wed Sep 2 > 07:58:52 2009 > +++ /trunk/user/src/com/google/gwt/user/client/ui/Button.java Wed Sep 2 > 10:55:41 2009 > @@ -54,7 +54,6 @@ > assert Document.get().getBody().isOrHasChild(element); > > Button button = new Button(element); > - assert "button".equalsIgnoreCase(button.getButtonElement().getType()); > > // Mark it attached and remember it for cleanup. > button.onAttach(); As I said when posting the initial patch, that was something I was"unsure about" (and I explicitly pointed out that it was breaking backwards compat') http://gwt-code-reviews.appspot.com/61809 ...but on the other hand, TextBox.wrap() has an assertion on type=text (actually in the TextBox(Element) ctor) which makes it unable to wrap an (use a PasswordTextBox for that) whereas PasswordTextBox doesn't add any particular method or behavior change to TextBox. This is a very similar situation to Button vs. SubmitButton and ResetButton. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
