[gwt-contrib] Re: Proposed Modification to PopupPanel
Emily, Would my various proposals for a pluggable event propagation mechanism help allow us to address this in a more generalized matter? -Ray On Wed, Dec 3, 2008 at 11:14 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > What about deprecating the old DOM.addEventPreview and creating an > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and > has some specialized methods to stop the event from going down the GWT > preview event chain. > > > > > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >> > Other Solutions: >> > >> > We considered passing the event preview down the existing stack of >> > EventPreview, which fixes the problem for more than just PopupPanels. >> > However, we think this approach is overkill because the problem really >> > doesn't manifest itself in other widgets. >> >> What about GlassPanel in the Incubator? Sounds like throwing a >> GlassPanel into the mix would break things since it isn't a subclass >> of PopupPanel and does it's own event previewing. >> >> >> On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> wrote: >> > Contributors - >> > >> > Summary: >> > >> > In the current implementation of PopupPanel, a PopupPanel with autoHide >> > enabled will not autoHide if another Widget (such as another PopupPanel) >> > steals the event preview. In practice, this means that if a PopupPanel >> > is >> > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no >> > longer autoHide. >> > >> > Consider an example where you have a SuggestBox inside of a PopupPanel >> > that >> > is autoHide. If you start typing in the SuggestBox, it opens a >> > PopupPanel >> > of suggestions. You then click outside the original popup and expect it >> > to >> > disappear. Instead, only the SuggestBox popup disappears. In this >> > case, >> > the PopupPanels are related, but in some cases they are not. If you use >> > a >> > sticky PopupPanel (stays open for a while, ex. a debug menu or log) in >> > your >> > app, it may steal preview from an autoHide PopupPanel, and you have to >> > close >> > one to close the other. >> > >> > >> > Proposed Solution: >> > == >> > I propose that we add a static stack of PopupPanels to the PopupPanel >> > class. As popups are shown and hidden, they are added and removed from >> > the >> > stack. When a popup recieves an event preview, it passes the event down >> > the >> > stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel >> > that >> > is modal. The first modal PopupPanel (which blocks events by >> > definition) >> > will end the event preview chain. >> > >> > >> > Example: >> > === >> > Consider the following stack of PopupPanels, where the top panel is the >> > last >> > one that is opened: >> > popup6 (autoHide) >> > popup5 >> > popup4 (autoHide) >> > popup3 (autoHide) >> > popup2 (modal) >> > popup1 (autoHide) >> > popup0 (modal) >> > >> > Now lets say you click on popup4: >> > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. >> > (NOTE: >> > usually, only popup6 gets to preview the event) >> > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so >> > ignore it. >> > 3. Popup4 previews the event. AutoHide is enabled, but the event >> > occured >> > over Popup4, so it is ignored. >> > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. >> > 5. Popup2 previews the event. Modal is enabled, so it ends the chain. >> > >> > Popup1 and Popup0 never preview the event, so they both remain open. >> > >> > >> > Other Solutions: >> > >> > We considered passing the event preview down the existing stack of >> > EventPreview, which fixes the problem for more than just PopupPanels. >> > However, we think this approach is overkill because the problem really >> > doesn't manifest itself in other widgets. >> > >> > Thanks, >> > John LaBanca >> > [EMAIL PROTECTED] >> > >> > > >> > >> >> > > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed Modification to PopupPanel
Excellent write up John. +1 for the more accessible solution. Some other uses of EventPreview beyond popups: * 3rd party dialogs (not extending PopupPanel) * Drag N Drop: mouse capture freezes the cursor in IE. If you want to change the cursor during a drag to indicate "Can't Drop" you have to go with Event Preview. * event tracing. Add an event preview at application startup, listen for a certain combination of keystrokes and start dumping events to the console. Currently breaks when popups / dialogs are show due to non-propagation of events up the chain. Another request for bubbling event preview: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/4e33c2ec460ec988/d281219105a4efc6 Cheers, -= Mat On Wed, Dec 3, 2008 at 11:14 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > What about deprecating the old DOM.addEventPreview and creating an > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and > has some specialized methods to stop the event from going down the GWT > preview event chain. > > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >> > Other Solutions: >> > >> > We considered passing the event preview down the existing stack of >> > EventPreview, which fixes the problem for more than just PopupPanels. >> > However, we think this approach is overkill because the problem really >> > doesn't manifest itself in other widgets. >> >> What about GlassPanel in the Incubator? Sounds like throwing a >> GlassPanel into the mix would break things since it isn't a subclass >> of PopupPanel and does it's own event previewing. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWTCanvas's strange behavior : timer driven animation frozen when move the mouse. (in IE, also happen when directly write vml markups)
PROBLEM DESCRIPTION: In IE, even simple shape(meaning very short path string) drawn with large pixel coordinate(meaning large shape), the animation get frozen when I keep moving the mouse over the shape. SOFTWARE: IE or host mode GWT Browser HARDWARE: AMD Dual-core 2GHz ATTACK THE PROBLEM: There are two possibilities why this kind of things happen: 1) google do a not so good wrapper upon VML and/or 2) M $ make a not so good markup language. Here is the experiment and result (both GWTCanvas code and directly written VML code behave the same way ): 1. make small(the size of the shape) and simple(the path string is short) shape: animation is fast without any doubt, even when keeping mouse moving. 2. make small and complex shape:animation is fast, even when keeping mouse moving. 3. make large and simple shape: animation is fast, but when keeping mouse moving over the shape, the animation stop. At last, it turn out to be the problem of M$. What puzzle me: what do the mouse-move event have to do with the timer event for the animation. There are two guesses: 1) mousemove event is of more priority than timer event in IE. 2) When mousemove event trigged, IE will do some time-consuming things (specially when the shape is large) even you didn't write any code in javascript(or GWT's event handling function) to handle the event. Does anyone have any idea about this strange behavior of IE. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Request for comments: the new 1.6 WAR deployment
I've created a design doc detailing our plans for the 1.6 WAR deployment change. Feedback is welcome, on the document as a whole or on open issues. Questions are also very welcome, and I will incorporate the answers into clarifying the doc. http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6 Summary In 1.5, GWTShellServlet served resources directly off the classpath (for public files), or generated files from a temporary location. This has the advantage of allowing fast refresh and resource updating, and making things "easy". However, it has the downside of not leaving the user with something that's easy to deploy. We will rectify the deployment issue in 1.6 by standardizing GWT around the "expanded WAR format". The two *key principles* are: 1. The result of running the GWT compiler (and possibly some associated tools/build rules) will be an expanded WAR directory structure that can be immediately deployed to a Java Servlet Container compatible web server. 2. Hosted mode will operate using essentially the same format, in the same directory, to ensure that hosted and compiled web applications behave the same. In 1.6, we always dump all resources directly into the WAR directory, which the server serves directly out of. We automate in hosted mode what a build process would do. This is triggered by the Hosted Browser actually executing a selection script; the selection script (when running hosted mode) forces a hosted mode link. Subsequent GWT.create() calls may cause incremental links. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: 1.6 date picker question
Hi John, Thank you for the reply. Are there any plans in the future to include various variations of the date picker for developers to choose from (which would be inline with the requests for a "richer" widget set)? -- Arthur Kalmenson On Mon, Dec 1, 2008 at 11:37 AM, John LaBanca <[EMAIL PROTECTED]> wrote: > [+ecc, +google-web-toolkit-contributors] > > The default DatePicker will only include next and previous buttons, but you > can replace the MonthSelector with your own that does any of the things you > suggest. We thought about using a fancy MonthSelector by default, but we > figured everyone would have a different opinion on the ideal version, so we > instead designed it so you can replace it. > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > On Mon, Dec 1, 2008 at 9:41 AM, Arthur Kalmenson <[EMAIL PROTECTED]> > wrote: >> >> Hello John, >> >> Will the 1.6 date picker include a year spinner? I know the current >> incubator version does not have a year spinner, so this makes it >> pretty difficult to use the date picker if you have a date that's more >> then a year off. Another nice feature would be to be able to select >> the date. For example you could click on the year the date picker >> shows, and that would turn it into a text box where you can enter the >> year you'd like. >> >> Best regards, >> -- >> Arthur Kalmenson > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4247 - wiki
Author: [EMAIL PROTECTED] Date: Wed Dec 3 18:26:41 2008 New Revision: 4247 Modified: wiki/WAR_Design_1_6.wiki Log: Edited 1.6 WAR design doc through web user interface. Modified: wiki/WAR_Design_1_6.wiki == --- wiki/WAR_Design_1_6.wiki(original) +++ wiki/WAR_Design_1_6.wikiWed Dec 3 18:26:41 2008 @@ -89,9 +89,11 @@ We will no longer use `GWTShellServlet` and embedded Tomcat. Instead, we will used Jetty by default, but allow other servers to be plugged in through a lightweight interface. # `HostedMode` performs an initial link for each module specified on the command line -# Public resources and a generated a default selection script are copied into `war/qualified.ModuleName/` - # `HostedMode` starts the web server, targeting it at war/. - # `HostedMode` launches a hosted browser window for each -startupUrl specified on the command line +# Public resources and a generated selection script are copied into `war/qualified.ModuleName/` +# The generated selection script will not override an existing compiled selection script; this is to prevent clobbering a compile +# No generator produced resources will be created + # `HostedMode` starts the web server, targeting it at `war/`. + # `HostedMode` launches a hosted browser window for each `-startupUrl` specified on the command line # The hosted browser requests the host HTML page from the server. # The host HTML page loads the generated selection script for the included modules. # The generated selection script recognizes the hosted browser environment and takes special action @@ -102,7 +104,7 @@ # The original selection script delegates to the new selection script in the module-session directory # The GWT module base url targets the new directory # The new selection script loads `hosted.html` into an `IFRAME`, and hosted mode continues bootstrapping as per 1.5 -# Whenever new resources are generated from a `GWT.create(`) resolution, an incremental link is performed into the module-session directory. +# Whenever new resources are generated from a `GWT.create()` resolution, an *incremental link* is performed into the module-session directory. # The new selection script hooks window closing, and triggers deletion of the module-session directory when the session is complete. # As a backup, a VM shutdown hook is used to delete any outstanding module-session directories. # If the user refreshes the page @@ -115,7 +117,14 @@ # A web browser then loads the host HTML page, which loads the compiled selection script. # The compiled selection script detects that it is not running in the hosted browser, and therefore loads web mode normally. +== Linker Stack Changes == + +The linker stack must now support hosted mode fully and correctly. When a hosted browser begins to load a GWT application, a module-session is created, and an initial link is performed into the module-session directory. This module-session is retained throughout the life of that hosted browser remaining on the page. The initial link takes only public resources as inputs, but should produce a selection script based on zero `CompilationResult`s. In the future, we may choose to synthesize a `HostedModeCompilationResult` to represent the actual deferred binding properties of the browser associated with the module-session. + +As the application runs, calls to `GWT.create()` may generate new resources. Each time new resources are generated, the linker stack will call a new `relink` method on all of the linkers in the stack, passing in the set of newly generated artifacts. Each linker must retain its own internal state if it needs to consider previously-encountered artifacts. The lifespan of a linker is guaranteed that each instance will be associated with exactly one module-session. + == Coordination with Eclipse Plugin == + Make sure that it expects to track the list of active modules for a given project. == Open Issues == @@ -129,7 +138,8 @@ # How will JUnit work? # Probably can use legacy stuff for now # Will this design work with Maven? + # Will the module-session idea negatively impact history / backing into an application? == Open Tasks == # Make sure app creator and sample follow this structure. - # Remove the GWT module deploy-to attribute introduced in the 1.6 branch. + # Remove the GWT module deploy-to attribute introduced in the 1.6 branch. \ No newline at end of file --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4246 - wiki
Author: [EMAIL PROTECTED]
Date: Wed Dec 3 18:07:29 2008
New Revision: 4246
Added:
wiki/WAR_Design_1_6.wiki
Log:
Created 1.6 WAR design doc through web user interface.
Added: wiki/WAR_Design_1_6.wiki
==
--- (empty file)
+++ wiki/WAR_Design_1_6.wikiWed Dec 3 18:07:29 2008
@@ -0,0 +1,135 @@
+#summary Plans for changes to GWT output for 1.6.
+
+= Design Doc for 1.6 WAR structure =
+
+In 1.5, `GWTShellServlet` served resources directly off the classpath (for
public files), or generated files from a temporary location. This has the
advantage of allowing fast refresh and resource updating, and making
things "easy". However, it has the downside of not leaving the user with
something that's easy to deploy.
+
+We will rectify the deployment issue in 1.6 by standardizing GWT around
the "expanded WAR format". The two *key principles* are:
+
+ # The result of running the GWT compiler (and possibly some associated
tools/build rules) will be an expanded WAR directory structure that can be
immediately deployed to a Java Servlet Container compatible web server.
+ # Hosted mode will operate using essentially the same format, in the
same directory, to ensure that hosted and compiled web applications behave
the same.
+
+In 1.6, we always dump all resources directly into the WAR directory,
which the server serves directly out of. We automate in hosted mode what a
build process would do. This is triggered by the Hosted Browser actually
executing a selection script; the selection script (when running hosted
mode) forces a hosted mode link. Subsequent `GWT.create()` calls may cause
incremental links.
+
+== Non-Goals / Off-the-table ==
+
+ * Produce a JS library or anything other than a standard GWT application
+ * Implement server code refresh within the hosted mode servlet container
+ * Implement a more complex project structure based on the idea of
a "source" war template which is automatically copied into the output war
directory; external tools could do this.
+
+== Proposed Simple GWT project structure ==
+{{{
+MyProject/
+ build.xml
+ src/
+
+ war/
+MyProject.html
+MyProject.jsp
+MyProject.css
+WEB-INF/
+ web.xml
+ classes/
+
+ lib/
+gwt-servlet.jar
+
+qualified.ModuleName/
+ qualified.ModuleName.nocache.js
+ public_resource.gif
+ generated_resource.png
+
+ scripts/
+STRONGNAME1.cache.js
+STRONGNAME2.cache.js
+
+qualified.ModuleName2/
+
+ extra/
+qualified.ModuleName/
+
+qualified.ModuleName2/
+
+}}}
+
+Note: the `extra/` subfolder will not be produced by default.
+
+== Changes in Suggested Best Practices ==
+
+The most key user-facing change is that we no longer suggest that host
HTML pages live in the public path of the application module. Instead, we
suggest that many static resources, most especially the host HTML page that
includes a GWT module, should live in the `war` directory as a static
resource rather than on the classpath.
+
+== Command Line Options, old vs. new ==
+
+In 1.5, the output level options work this way:
+
+ * `-out` is respected by both GWTCompiler and GWTShell, it represents
the "root" output folder
+* Defaults to the current working directory
+ * Deployable files go into `out/qualified.moduleName/`
+ * Non-deployed files go into `out/qualified.ModuleName-aux/`
+ * Extra cruft is created in `out/.gwt-tmp/`
+
+This situation is undesirable because it the out directory is not
immediately useful without addition build rules and processing. We propose
for 1.6 that the output be in standard expanded WAR format. We will retain
`GWTCompiler` and `GWTShell` for backwards-compatibility with 1.5, but
newly created projects will use new entry points, `Compile` and
`HostedMode`.
+
+ * `-war` is used to specify the WAR output folder
+* The default value is /war
+ * `-extra` is used to specify the output folder for non-deployed linker
artifacts
+* The default value is to not produce extra output
+ * `-server` can be used to specify what server should be run
+* The argument is the name of a class which implements a
`ServletContainerLauncher` interface; details TBD
+* The default value is to launch a Jetty server, which will we
distribute with GWT
+* `-noserver` can be used to run no server at all
+ * `HostedMode` requires a list of modules to serve as the default
argument
+* `-startupUrl` is optionally (but canonically) used to launch one or
more urls in the hosted browser on startup, which is what GWTShell used to
use the default argument for
+ * `Co
[gwt-contrib] Date picker branch code review requested: style methods renamed, varargs fixed
http://code.google.com/p/google-web-toolkit/source/detail?r=4245 Renames some methods to reduce the confusion between global and not global styles. Also fixes various varargs methods, which weren't really working. We now have styles (formerly global styles) and transient styles, the latter of which can only be applied to visible dates. The transient word appears in the former setEnabled method as well, for consistency. Removes separate methods for removing global and transient styles, as the former method would always remove the transient styles anyway, and it seems very unlikely that a client will use the same style name for both a transient and permanent date style. Adds unit tests for styles and enabling. TBR: ecc submitter: rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4245 - in branches/1_6_datepicker/user: src/com/google/gwt/user/datepicker/client test/com/googl...
Author: [EMAIL PROTECTED]
Date: Wed Dec 3 17:53:46 2008
New Revision: 4245
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DefaultCalendarView.java
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/DatePickerTest.java
Log:
Renames some methods to reduce the confusion between global and not
global styles. Also fixes various varargs methods, which weren't
really working.
We now have styles (formerly global styles) and transient styles, the
latter of which can only be applied to visible dates. The transient word
appears in the former setEnabled method as well, for consistency.
Removes separate methods for removing global and transient styles, as
the former method would always remove the transient styles anyway, and
it seems very unlikely that a client will use the same style name for
both a transient and permanent date style.
Adds unit tests for styles and enabling.
TBR: ecc
submitter: rjrjr
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Wed Dec 3 17:53:46 2008
@@ -31,7 +31,6 @@
import java.util.Date;
import java.util.HashMap;
-import java.util.Iterator;
import java.util.Map;
/**
@@ -211,14 +210,13 @@
info.put(key, current + styleName);
}
} else {
-assert current != null : "Removing style " + styleName + " from
date "
-+ d + " but the style name wasn't there";
-
-String newValue = current.replaceAll(styleName, "");
-if (newValue.trim().length() == 0) {
- info.remove(key);
-} else {
- info.put(key, newValue);
+if (current != null) {
+ String newValue = current.replaceAll(styleName, "");
+ if (newValue.trim().length() == 0) {
+info.remove(key);
+ } else {
+info.put(key, newValue);
+ }
}
}
}
@@ -267,31 +265,17 @@
this.setup();
setCurrentMonth(new Date());
-addGlobalStyleToDate(css().dayIsToday(), new Date());
- }
-
- /**
- * Globally adds a style name to a date. i.e. the style name is
associated
- * with the date each time it is rendered.
- *
- * @param styleName style name
- * @param date date
- */
- public void addGlobalStyleToDate(String styleName, Date date) {
-styler.setStyleName(date, styleName, true);
-if (isDateVisible(date)) {
- getView().addStyleToDate(styleName, date);
-}
+addStyleToDates(css().dayIsToday(), new Date());
}
public HandlerRegistration addHighlightHandler(HighlightHandler
handler) {
return addHandler(handler, HighlightEvent.getType());
}
-
+
public HandlerRegistration addShowRangeHandler(ShowRangeHandler
handler) {
return addHandler(handler, ShowRangeEvent.getType());
}
-
+
/**
* Adds a show range handler and immediately activate the handler on the
* current view.
@@ -309,35 +293,63 @@
}
/**
- * Shows the given style name on the specified date. This is only set
until
- * the next time the DatePicker is refreshed.
- *
- * @param styleName style name
- * @param date visible date
- * @param moreDates optional visible dates
+ * Add a style name to the given dates.
*/
- public final void addStyleToVisibleDates(String styleName, Date date,
- Date... moreDates) {
-assert (assertVisible(date, moreDates));
+ public void addStyleToDates(String styleName, Date date) {
+styler.setStyleName(date, styleName, true);
+if (isDateVisible(date)) {
+ getView().addStyleToDate(styleName, date);
+}
+ }
+
+ /**
+ * Add a style name to the given dates.
+ */
+ public void addStyleToDates(String styleName, Date date, Date...
moreDates) {
+addStyleToDates(styleName, date);
+for (Date d : moreDates) {
+ addStyleToDates(styleName, d);
+}
+ }
+
+ /**
+ * Add a style name to the given dates.
+ */
+ public void addStyleToDates(String styleName, Iterable dates) {
+for (Date d : dates) {
+ addStyleToDates(styleName, d);
+}
+ }
+
+ /**
+ * Adds the given style name to the specified dates, which must be
visible.
+ * This is only set until the next time the DatePicker is refreshed.
+ */
+ public void addTransientStyleToVisibleDates(String styleName, Date date)
{
+assert isDateVisible(date) : date + " must be visible";
getView().addStyleToDate(styleName, date);
-if (moreDates != null) {
- for (Date d : moreDates) {
-getView().addStyleToDate(styleName, d);
- }
+ }
+
+ /**
+ * Adds the give
[gwt-contrib] Re: Problem with certain failure cases in GWTTestCase
On Wed, Dec 3, 2008 at 3:11 PM, Joel Webber <[EMAIL PROTECTED]> wrote: > So here are all the ways I can think of for a test method to complete, > either synchronously or asynchronously. Those not explicitly marked as such > work properly. > > Normal synchronous test methods: > - Test method completes successfully and synchronously. > - Test method triggers an exception synchronously (*not* from within an > event handler). > > Normal asynchronous test methods: > - Test method goes into async mode, returns, then passes (called > finishTest()). > - Test method goes into async mode, returns, then fails by triggering an > exception in an event handler. > - Test method goes into async mode, returns, then fails by timing out. > > Weird cases: > - Test method triggers an exception synchronously *from an event handler*. > - As described above, the exception is thrown away from GWTTestCase's > onUncaughtException(). > - Test method completes synchronously, then triggers an exception between > test methods. > - Uncertain, but I believe it just throws away the exception, as in the > above case. > It would throw it away. This is kind of the weirdest case, because you've actually already reported a result for a case that you later discover failed, and you're waiting on an XHR to see what to run next. I suppose you could immediately fail the *next* test once it's ready with a PreviouslyFailedTestException. > - Test method completes [a]synchronously, then triggers an exception during > the next test method. > - The delayed exception causes the *next* test to report failure, which > seems somewhat wrong. > - But the stack trace still shows the actual point where the exception > occurred. > > What those last to "weird cases" lead me to believe is that we're not > really defending against anything by throwing away uncaught exceptions, and > that we should be able to allow all uncaught exceptions to 'fail' the > current test (even if it ends up being the wrong one). Are there any other > cases I'm missing here, or some subtle reason we can't do this? > This seems reasonable, I just wanted to enumerate the cases and make sure it makes sense. Other weird cases I can think of (there may be more): - Test method triggers an exception synchronously after setting up an async state - Test method triggers an exception synchronously *from an event handler* after setting up an async state (but before the method returns) - Test method triggers an exception synchronously *from an event handler*, then throws an exception itself synchronously. (We report a CaughtPlusUncaughtAtTheSameTimeException that contains both?) :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4244 - in changes/jat/oophm-plugins-trunk/plugins: . common
Author: [EMAIL PROTECTED] Date: Wed Dec 3 17:11:00 2008 New Revision: 4244 Added: changes/jat/oophm-plugins-trunk/plugins/config.mk Removed: changes/jat/oophm-plugins-trunk/plugins/common/Makefile.mac Modified: changes/jat/oophm-plugins-trunk/plugins/common/Makefile Log: Commit missing files from previous commit to change branch. Modified: changes/jat/oophm-plugins-trunk/plugins/common/Makefile == --- changes/jat/oophm-plugins-trunk/plugins/common/Makefile (original) +++ changes/jat/oophm-plugins-trunk/plugins/common/Makefile Wed Dec 3 17:11:00 2008 @@ -1,10 +1,4 @@ -# Set to classpath value to get GWT classes from -#GWTDEV=../build/staging/gwt-linux-0.0.0/gwt-dev-linux.jar -GWTDEV=../eclipse/dev/linux/bin - -INC=-I.. -CFLAGS=-Wall -g -O2 -fPIC $(INC) -rdynamic -CXXFLAGS=$(CFLAGS) +include ../config.mk HDRS= HostChannel.h InvokeMessage.h LoadModuleMessage.h Message.h \ ReturnMessage.h Value.h BrowserChannel.h Debug.h DebugLevel.h \ @@ -12,88 +6,74 @@ LoadJsniMessage.h InvokeSpecialMessage.h FreeValueMessage.h \ ByteOrder.h -OBJS= HostChannel.o LoadModuleMessage.o InvokeMessage.o \ - ReturnMessage.o ServerMethods.o Debug.o Socket.o \ - AllowedConnections.o LoadJsniMessage.o InvokeSpecialMessage.o \ - FreeValueMessage.o - SRCS= HostChannel.cpp LoadModuleMessage.cpp InvokeMessage.cpp \ ReturnMessage.cpp ServerMethods.cpp Debug.cpp Socket.cpp \ AllowedConnections.cpp LoadJsniMessage.cpp InvokeSpecialMessage.cpp \ FreeValueMessage.cpp -OBJ32= $(patsubst %.cpp,obj32/%.o,$(SRCS)) -OBJ64= $(patsubst %.cpp,obj64/%.o,$(SRCS)) - -#all:: libcommon32.a libcommon64.a -all:: libcommon32.a - -libcommon32.a: $(OBJ32) obj32.dir - ar -rv $@ $(OBJ32) +LIBCOMMON= libcommon$(FLAG32BIT).a +OBJDIR= obj$(FLAG32BIT) +OBJS= $(patsubst %.cpp,$(OBJDIR)/%.o,$(SRCS)) -libcommon64.a: $(OBJ64) obj64.dir - ar -rv $@ $(OBJ64) +all:: $(OBJDIR) $(LIBCOMMON) -obj32.dir: - -mkdir obj32 - touch obj32.dir +$(OBJDIR): + -mkdir $@ -obj64.dir: - -mkdir obj64 - touch obj64.dir +$(LIBCOMMON): $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) -obj32/%.o: %.cpp obj32.dir - $(CXX) $(CXXFLAGS) -m32 -c $< -o $@ - -obj64/%.o: %.cpp obj64.dir - $(CXX) $(CXXFLAGS) -m64 -c $< -o $@ +$(OBJDIR)/%.o: %.cpp + $(CXX) $(CXXFLAGS) -c $< -o $@ .PHONY: clean depend testdebug testdebug: (cd testing; CXX=$(CXX) CXXFLAGS="$(CFLAGS) -m32" ./testdebug) (cd testing; CXX=$(CXX) CXXFLAGS="$(CFLAGS) -m64" ./testdebug) + clean: - rm $(OBJ32) $(OBJ64) libcommon32.a libcommon64.a + rm -rf obj32 obj64 libcommon32.a libcommon64.a depend: g++ -MM $(CFLAGS) $(SRCS) >>Makefile # makedepend -- $(CFLAGS) -- $(SRCS) # DO NOT DELETE -obj32/HostChannel.o obj64/HostChannel.o: HostChannel.cpp Debug.h Platform.h \ - DebugLevel.h FreeValueMessage.h Message.h BrowserChannel.h HostChannel.h \ +HostChannel.o: HostChannel.cpp Debug.h Platform.h DebugLevel.h \ + ByteOrder.h FreeValueMessage.h Message.h BrowserChannel.h HostChannel.h \ Socket.h AllowedConnections.h ReturnMessage.h Value.h SessionHandler.h \ LoadJsniMessage.h InvokeMessage.h InvokeSpecialMessage.h QuitMessage.h \ scoped_ptr/scoped_ptr.h -obj32/LoadModuleMessage.o obj64/LoadModuleMessage.o: LoadModuleMessage.cpp Debug.h Platform.h \ +LoadModuleMessage.o: LoadModuleMessage.cpp Debug.h Platform.h \ DebugLevel.h LoadModuleMessage.h Message.h BrowserChannel.h \ - HostChannel.h Socket.h AllowedConnections.h ReturnMessage.h Value.h \ - SessionHandler.h scoped_ptr/scoped_ptr.h -obj32/InvokeMessage.o obj64/InvokeMessage.o: InvokeMessage.cpp InvokeMessage.h Message.h \ + HostChannel.h ByteOrder.h Socket.h AllowedConnections.h ReturnMessage.h \ + Value.h SessionHandler.h scoped_ptr/scoped_ptr.h +InvokeMessage.o: InvokeMessage.cpp InvokeMessage.h Message.h \ BrowserChannel.h Value.h Debug.h Platform.h DebugLevel.h HostChannel.h \ - Socket.h AllowedConnections.h ReturnMessage.h SessionHandler.h \ - scoped_ptr/scoped_ptr.h -obj32/ReturnMessage.o obj64/ReturnMessage.o: ReturnMessage.cpp ReturnMessage.h Message.h \ + ByteOrder.h Socket.h AllowedConnections.h ReturnMessage.h \ + SessionHandler.h scoped_ptr/scoped_ptr.h +ReturnMessage.o: ReturnMessage.cpp ReturnMessage.h Message.h \ BrowserChannel.h Value.h Debug.h Platform.h DebugLevel.h HostChannel.h \ - Socket.h AllowedConnections.h SessionHandler.h -obj32/ServerMethods.o obj64/ServerMethods.o: ServerMethods.cpp Debug.h Platform.h DebugLevel.h \ - FreeValueMessage.h Message.h BrowserChannel.h HostChannel.h Socket.h \ - AllowedConnections.h ReturnMessage.h Value.h SessionHandler.h \ + ByteOrder.h Socket.h AllowedConnections.h SessionHandler.h +ServerMethods.o: ServerMethods.cpp Debug.h Platform.h DebugLevel.h \ + FreeValueMessage.h Message.h BrowserChannel.h Host
[gwt-contrib] [google-web-toolkit commit] r4243 - trunk/dev/oophm/src/com/google/gwt/dev
Author: [EMAIL PROTECTED]
Date: Wed Dec 3 15:49:52 2008
New Revision: 4243
Modified:
trunk/dev/oophm/src/com/google/gwt/dev/ModulePanel.java
Log:
Remove JDK 1.6 dependency from OOPHM shell.
Patch by: jat
Review by: scottb (TBR)
Modified: trunk/dev/oophm/src/com/google/gwt/dev/ModulePanel.java
==
--- trunk/dev/oophm/src/com/google/gwt/dev/ModulePanel.java (original)
+++ trunk/dev/oophm/src/com/google/gwt/dev/ModulePanel.java Wed Dec 3
15:49:52 2008
@@ -26,7 +26,6 @@
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
-import javax.swing.BorderFactory;
import javax.swing.ImageIcon;
import javax.swing.JButton;
import javax.swing.JLabel;
@@ -47,9 +46,6 @@
public ClosedTabComponent() {
super(new FlowLayout(FlowLayout.LEFT, 0, 0));
setOpaque(false);
- JLabel label = new JLabel("Disconnected");
- add(label);
- label.setBorder(BorderFactory.createEmptyBorder(0, 0, 0, 5));
JButton button = new JButton(closeIcon);
button.setBorderPainted(false);
button.setPreferredSize(new Dimension(closeIcon.getIconWidth(),
@@ -78,11 +74,13 @@
private final JTabbedPane tabs;
+ private JPanel topPanel;
+
public ModulePanel(Type maxLevel, String moduleName, String userAgent,
String remoteSocket, final JTabbedPane tabs) {
super(new BorderLayout());
this.tabs = tabs;
-JPanel topPanel = new JPanel();
+topPanel = new JPanel();
topPanel.add(new JLabel(moduleName));
JButton compileButton = new JButton("Compile (not yet implemented)");
compileButton.setEnabled(false);
@@ -120,10 +118,12 @@
}
public void disconnect() {
+topPanel.add(new ClosedTabComponent());
synchronized (tabs) {
int index = tabs.indexOfComponent(this);
if (index > -1) {
-tabs.setTabComponentAt(index, new ClosedTabComponent());
+tabs.setTitleAt(index, "Disconnected");
+tabs.setIconAt(index, null);
}
}
loggerPanel.disconnected();
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4242 - in trunk/dev/oophm: overlay/com/google/gwt/dev overlay/com/google/gwt/dev/shell src/com/g...
Author: [EMAIL PROTECTED]
Date: Wed Dec 3 15:31:00 2008
New Revision: 4242
Modified:
trunk/dev/oophm/overlay/com/google/gwt/dev/GWTShell.java
trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValue.java
trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValueGlue.java
trunk/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
trunk/dev/oophm/src/com/google/gwt/dev/shell/MethodDispatch.java
trunk/dev/oophm/src/com/google/gwt/dev/shell/ModuleSpaceOOPHM.java
Log:
OOPHM Checkstyle warning removal.
Patch by: jat
Review by: scottb (TBR)
Modified: trunk/dev/oophm/overlay/com/google/gwt/dev/GWTShell.java
==
--- trunk/dev/oophm/overlay/com/google/gwt/dev/GWTShell.java(original)
+++ trunk/dev/oophm/overlay/com/google/gwt/dev/GWTShell.javaWed Dec 3
15:31:00 2008
@@ -308,6 +308,12 @@
}
}
+public ModuleSpaceHost createModuleSpaceHost(BrowserWidget widget,
+String moduleName) throws UnableToCompleteException {
+ // TODO(jat): implement method createModuleSpaceHost
+ return null;
+}
+
public ModuleSpaceHost createModuleSpaceHost(TreeLogger mainLogger,
String moduleName, String userAgent, String remoteSocket)
throws UnableToCompleteException {
@@ -365,6 +371,12 @@
return GWTShell.this.normalizeURL(whatTheUserTyped);
}
+public BrowserWidget openNewBrowserWindow()
+throws UnableToCompleteException {
+ // TODO(jat): is this ok?
+ throw new UnableToCompleteException();
+}
+
public void unloadModule(ModuleSpaceHost moduleSpaceHost) {
ModulePanel tab = moduleTabs.remove(moduleSpaceHost);
if (tab != null) {
@@ -389,18 +401,6 @@
alreadySeenModules.add(moduleName);
assert (moduleDef != null) : "Required module state is absent";
return moduleDef;
-}
-
-public ModuleSpaceHost createModuleSpaceHost(BrowserWidget widget,
-String moduleName) throws UnableToCompleteException {
- // TODO(jat): implement method createModuleSpaceHost
- return null;
-}
-
-public BrowserWidget openNewBrowserWindow()
-throws UnableToCompleteException {
- // TODO(jat): is this ok?
- throw new UnableToCompleteException();
}
}
Modified: trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValue.java
==
--- trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValue.java
(original)
+++ trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValue.java Wed Dec
3 15:31:00 2008
@@ -213,7 +213,7 @@
/**
* Set the JS object to be null.
*
- * @throws HostedModeException
+ * @throws com.google.gwt.dev.shell.HostedModeException
*/
public abstract void setNull();
Modified: trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValueGlue.java
==
--- trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValueGlue.java
(original)
+++ trunk/dev/oophm/overlay/com/google/gwt/dev/shell/JsValueGlue.java Wed
Dec 3 15:31:00 2008
@@ -87,8 +87,8 @@
* @param type expected type of the returned object
* @param msgPrefix a prefix for error/warning messages
* @return the object reference
- * @throws HostedModeException if the JavaScript object is not
assignable to
- * the supplied type.
+ * @throws com.google.gwt.dev.shell.HostedModeException if the JavaScript
+ * object is not assignable to the supplied type.
*/
@SuppressWarnings("unchecked")
public static T get(JsValue value, CompilingClassLoader cl,
Modified:
trunk/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
==
--- trunk/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(original)
+++ trunk/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
Wed Dec 3 15:31:00 2008
@@ -89,15 +89,15 @@
convertToJsValue(ccl, remoteObjects, returnValue, returnJsValue);
if (msg.isException()) {
if (returnValue.isNull() || returnValue.isUndefined()) {
- throw ModuleSpaceOOPHM.createJavaScriptException(ccl, null);
+ throw ModuleSpace.createJavaScriptException(ccl, null);
} else if (returnValue.isString()) {
- throw ModuleSpaceOOPHM.createJavaScriptException(ccl,
+ throw ModuleSpace.createJavaScriptException(ccl,
returnValue.getString());
} else if (returnValue.isJsObject()) {
Object jso = JsValueGlue.createJavaScriptObject(returnJsValue,
ccl);
- throw ModuleSpaceOOPHM.createJavaScriptException(ccl, jso);
+ throw ModuleSpace.createJavaScriptException(ccl, jso);
} else if (returnValue.isJavaObject(
[gwt-contrib] Re: Proposed Modification to PopupPanel
Good point! Joel, where are your trigger event methods going? On Wed, Dec 3, 2008 at 4:24 PM, John LaBanca <[EMAIL PROTECTED]> wrote: > +1 > > I think DOM is on its way out. Maybe we can add the method to Window, > Document, or even Event? > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > On Wed, Dec 3, 2008 at 4:19 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > >> >> Sounds good. I don't do a lot with event preview, but it seems >> reasonable that it should follow the new event model. >> >> On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: >> > What about deprecating the old DOM.addEventPreview and creating an >> > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent >> and >> > has some specialized methods to stop the event from going down the GWT >> > preview event chain. >> > >> > >> > >> > >> > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >> >> >> > Other Solutions: >> >> > >> >> > We considered passing the event preview down the existing stack of >> >> > EventPreview, which fixes the problem for more than just PopupPanels. >> >> > However, we think this approach is overkill because the problem >> really >> >> > doesn't manifest itself in other widgets. >> >> >> >> What about GlassPanel in the Incubator? Sounds like throwing a >> >> GlassPanel into the mix would break things since it isn't a subclass >> >> of PopupPanel and does it's own event previewing. >> >> >> >> >> >> On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> >> wrote: >> >> > Contributors - >> >> > >> >> > Summary: >> >> > >> >> > In the current implementation of PopupPanel, a PopupPanel with >> autoHide >> >> > enabled will not autoHide if another Widget (such as another >> PopupPanel) >> >> > steals the event preview. In practice, this means that if a >> PopupPanel >> >> > is >> >> > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will >> no >> >> > longer autoHide. >> >> > >> >> > Consider an example where you have a SuggestBox inside of a >> PopupPanel >> >> > that >> >> > is autoHide. If you start typing in the SuggestBox, it opens a >> >> > PopupPanel >> >> > of suggestions. You then click outside the original popup and expect >> it >> >> > to >> >> > disappear. Instead, only the SuggestBox popup disappears. In this >> >> > case, >> >> > the PopupPanels are related, but in some cases they are not. If you >> use >> >> > a >> >> > sticky PopupPanel (stays open for a while, ex. a debug menu or log) >> in >> >> > your >> >> > app, it may steal preview from an autoHide PopupPanel, and you have >> to >> >> > close >> >> > one to close the other. >> >> > >> >> > >> >> > Proposed Solution: >> >> > == >> >> > I propose that we add a static stack of PopupPanels to the PopupPanel >> >> > class. As popups are shown and hidden, they are added and removed >> from >> >> > the >> >> > stack. When a popup recieves an event preview, it passes the event >> down >> >> > the >> >> > stack and lets each PopupPanel preview it UNTIL it reaches a >> PopupPanel >> >> > that >> >> > is modal. The first modal PopupPanel (which blocks events by >> >> > definition) >> >> > will end the event preview chain. >> >> > >> >> > >> >> > Example: >> >> > === >> >> > Consider the following stack of PopupPanels, where the top panel is >> the >> >> > last >> >> > one that is opened: >> >> > popup6 (autoHide) >> >> > popup5 >> >> > popup4 (autoHide) >> >> > popup3 (autoHide) >> >> > popup2 (modal) >> >> > popup1 (autoHide) >> >> > popup0 (modal) >> >> > >> >> > Now lets say you click on popup4: >> >> > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. >> >> > (NOTE: >> >> > usually, only popup6 gets to preview the event) >> >> > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, >> so >> >> > ignore it. >> >> > 3. Popup4 previews the event. AutoHide is enabled, but the event >> >> > occured >> >> > over Popup4, so it is ignored. >> >> > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. >> >> > 5. Popup2 previews the event. Modal is enabled, so it ends the >> chain. >> >> > >> >> > Popup1 and Popup0 never preview the event, so they both remain open. >> >> > >> >> > >> >> > Other Solutions: >> >> > >> >> > We considered passing the event preview down the existing stack of >> >> > EventPreview, which fixes the problem for more than just PopupPanels. >> >> > However, we think this approach is overkill because the problem >> really >> >> > doesn't manifest itself in other widgets. >> >> > >> >> > Thanks, >> >> > John LaBanca >> >> > [EMAIL PROTECTED] >> >> > >> >> > > >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > "There are only 10 types of people in the world: Those who understand >> > binary, and those who don't" >> > >> > > >> > >> >> >> > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don
[gwt-contrib] Re: Proposed Modification to PopupPanel
+1 I think DOM is on its way out. Maybe we can add the method to Window, Document, or even Event? Thanks, John LaBanca [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 4:19 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > > Sounds good. I don't do a lot with event preview, but it seems > reasonable that it should follow the new event model. > > On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > What about deprecating the old DOM.addEventPreview and creating an > > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent > and > > has some specialized methods to stop the event from going down the GWT > > preview event chain. > > > > > > > > > > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > >> > >> > Other Solutions: > >> > > >> > We considered passing the event preview down the existing stack of > >> > EventPreview, which fixes the problem for more than just PopupPanels. > >> > However, we think this approach is overkill because the problem really > >> > doesn't manifest itself in other widgets. > >> > >> What about GlassPanel in the Incubator? Sounds like throwing a > >> GlassPanel into the mix would break things since it isn't a subclass > >> of PopupPanel and does it's own event previewing. > >> > >> > >> On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> > wrote: > >> > Contributors - > >> > > >> > Summary: > >> > > >> > In the current implementation of PopupPanel, a PopupPanel with > autoHide > >> > enabled will not autoHide if another Widget (such as another > PopupPanel) > >> > steals the event preview. In practice, this means that if a > PopupPanel > >> > is > >> > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will > no > >> > longer autoHide. > >> > > >> > Consider an example where you have a SuggestBox inside of a PopupPanel > >> > that > >> > is autoHide. If you start typing in the SuggestBox, it opens a > >> > PopupPanel > >> > of suggestions. You then click outside the original popup and expect > it > >> > to > >> > disappear. Instead, only the SuggestBox popup disappears. In this > >> > case, > >> > the PopupPanels are related, but in some cases they are not. If you > use > >> > a > >> > sticky PopupPanel (stays open for a while, ex. a debug menu or log) in > >> > your > >> > app, it may steal preview from an autoHide PopupPanel, and you have to > >> > close > >> > one to close the other. > >> > > >> > > >> > Proposed Solution: > >> > == > >> > I propose that we add a static stack of PopupPanels to the PopupPanel > >> > class. As popups are shown and hidden, they are added and removed > from > >> > the > >> > stack. When a popup recieves an event preview, it passes the event > down > >> > the > >> > stack and lets each PopupPanel preview it UNTIL it reaches a > PopupPanel > >> > that > >> > is modal. The first modal PopupPanel (which blocks events by > >> > definition) > >> > will end the event preview chain. > >> > > >> > > >> > Example: > >> > === > >> > Consider the following stack of PopupPanels, where the top panel is > the > >> > last > >> > one that is opened: > >> > popup6 (autoHide) > >> > popup5 > >> > popup4 (autoHide) > >> > popup3 (autoHide) > >> > popup2 (modal) > >> > popup1 (autoHide) > >> > popup0 (modal) > >> > > >> > Now lets say you click on popup4: > >> > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. > >> > (NOTE: > >> > usually, only popup6 gets to preview the event) > >> > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, > so > >> > ignore it. > >> > 3. Popup4 previews the event. AutoHide is enabled, but the event > >> > occured > >> > over Popup4, so it is ignored. > >> > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. > >> > 5. Popup2 previews the event. Modal is enabled, so it ends the chain. > >> > > >> > Popup1 and Popup0 never preview the event, so they both remain open. > >> > > >> > > >> > Other Solutions: > >> > > >> > We considered passing the event preview down the existing stack of > >> > EventPreview, which fixes the problem for more than just PopupPanels. > >> > However, we think this approach is overkill because the problem really > >> > doesn't manifest itself in other widgets. > >> > > >> > Thanks, > >> > John LaBanca > >> > [EMAIL PROTECTED] > >> > > >> > > > >> > > >> > >> > > > > > > > > -- > > "There are only 10 types of people in the world: Those who understand > > binary, and those who don't" > > > > > > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed Modification to PopupPanel
Sounds good. I don't do a lot with event preview, but it seems reasonable that it should follow the new event model. On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > What about deprecating the old DOM.addEventPreview and creating an > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and > has some specialized methods to stop the event from going down the GWT > preview event chain. > > > > > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >> > Other Solutions: >> > >> > We considered passing the event preview down the existing stack of >> > EventPreview, which fixes the problem for more than just PopupPanels. >> > However, we think this approach is overkill because the problem really >> > doesn't manifest itself in other widgets. >> >> What about GlassPanel in the Incubator? Sounds like throwing a >> GlassPanel into the mix would break things since it isn't a subclass >> of PopupPanel and does it's own event previewing. >> >> >> On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> wrote: >> > Contributors - >> > >> > Summary: >> > >> > In the current implementation of PopupPanel, a PopupPanel with autoHide >> > enabled will not autoHide if another Widget (such as another PopupPanel) >> > steals the event preview. In practice, this means that if a PopupPanel >> > is >> > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no >> > longer autoHide. >> > >> > Consider an example where you have a SuggestBox inside of a PopupPanel >> > that >> > is autoHide. If you start typing in the SuggestBox, it opens a >> > PopupPanel >> > of suggestions. You then click outside the original popup and expect it >> > to >> > disappear. Instead, only the SuggestBox popup disappears. In this >> > case, >> > the PopupPanels are related, but in some cases they are not. If you use >> > a >> > sticky PopupPanel (stays open for a while, ex. a debug menu or log) in >> > your >> > app, it may steal preview from an autoHide PopupPanel, and you have to >> > close >> > one to close the other. >> > >> > >> > Proposed Solution: >> > == >> > I propose that we add a static stack of PopupPanels to the PopupPanel >> > class. As popups are shown and hidden, they are added and removed from >> > the >> > stack. When a popup recieves an event preview, it passes the event down >> > the >> > stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel >> > that >> > is modal. The first modal PopupPanel (which blocks events by >> > definition) >> > will end the event preview chain. >> > >> > >> > Example: >> > === >> > Consider the following stack of PopupPanels, where the top panel is the >> > last >> > one that is opened: >> > popup6 (autoHide) >> > popup5 >> > popup4 (autoHide) >> > popup3 (autoHide) >> > popup2 (modal) >> > popup1 (autoHide) >> > popup0 (modal) >> > >> > Now lets say you click on popup4: >> > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. >> > (NOTE: >> > usually, only popup6 gets to preview the event) >> > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so >> > ignore it. >> > 3. Popup4 previews the event. AutoHide is enabled, but the event >> > occured >> > over Popup4, so it is ignored. >> > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. >> > 5. Popup2 previews the event. Modal is enabled, so it ends the chain. >> > >> > Popup1 and Popup0 never preview the event, so they both remain open. >> > >> > >> > Other Solutions: >> > >> > We considered passing the event preview down the existing stack of >> > EventPreview, which fixes the problem for more than just PopupPanels. >> > However, we think this approach is overkill because the problem really >> > doesn't manifest itself in other widgets. >> > >> > Thanks, >> > John LaBanca >> > [EMAIL PROTECTED] >> > >> > > >> > >> >> > > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Problem with certain failure cases in GWTTestCase
Scott,
I'm looking into the problem we discussed with GWTTestCase exceptions, and I
think I have all the cases characterized now.
--- for the edidification of gwt-contrib ---
I'm writing some code to allow you to trigger events (a la
createEvent()/dispatchEvent()), primarily for testing purposes, and ran into
a problem testing them with GWTTestCase. If you write a test like the
following:
public void testTriggerScrollEvent() {
init();
NonBubbleAssertingEventListener listener =
newNonBubbleAssertingEventListener(
"scroll") {
public void onBrowserEvent(Event event) {
super.onBrowserEvent(event);
assertEquals("scroll", event.getType());
}
};
Event.setEventListener(parent, listener);
Event.setEventListener(child, listener);
Event.triggerScrollEvent(child);
assertTrue("Expected child to receive event", listener.childReceived);
}
... and the assertEquals("scroll", event.getType()) fails, GWTTestCase
catches it in its UncaughtExceptionHandler, which looks something like this:
public void onUncaughtException(Throwable ex) {
if (mainTestHasRun && timer != null) {
// Asynchronous mode; uncaught exceptions cause an immediate
failure.
assert (!testIsFinished);
reportResultsAndRunNextMethod(ex);
} else {
// just ignore it
}
}
... but because the event was triggered synchronously, the first test fails
(i.e. it's not running in async mode), and the exception gets lost, so your
tests appear to pass. This code appears to have been put in place to guard
against spurious async exceptions between test methods.
--- end edification ---
So here are all the ways I can think of for a test method to complete,
either synchronously or asynchronously. Those not explicitly marked as such
work properly.
Normal synchronous test methods:
- Test method completes successfully and synchronously.
- Test method triggers an exception synchronously (*not* from within an
event handler).
Normal asynchronous test methods:
- Test method goes into async mode, returns, then passes (called
finishTest()).
- Test method goes into async mode, returns, then fails by triggering an
exception in an event handler.
- Test method goes into async mode, returns, then fails by timing out.
Weird cases:
- Test method triggers an exception synchronously *from an event handler*.
- As described above, the exception is thrown away from GWTTestCase's
onUncaughtException().
- Test method completes synchronously, then triggers an exception between
test methods.
- Uncertain, but I believe it just throws away the exception, as in the
above case.
- Test method completes [a]synchronously, then triggers an exception during
the next test method.
- The delayed exception causes the *next* test to report failure, which
seems somewhat wrong.
- But the stack trace still shows the actual point where the exception
occurred.
What those last to "weird cases" lead me to believe is that we're not really
defending against anything by throwing away uncaught exceptions, and that we
should be able to allow all uncaught exceptions to 'fail' the current test
(even if it ends up being the wrong one). Are there any other cases I'm
missing here, or some subtle reason we can't do this?
Thanks,
joel.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
On Wed, Dec 3, 2008 at 10:10 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote: > (Spoiler alert: I'm going to start advocating hard in 2009 to get rid of > module XML altogether and use package and class annotations instead.) Everybody's ears are pricking up. Let's do that, yeah! :) -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed Modification to PopupPanel
What about deprecating the old DOM.addEventPreview and creating an DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and has some specialized methods to stop the event from going down the GWT preview event chain. On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > > > Other Solutions: > > > > We considered passing the event preview down the existing stack of > > EventPreview, which fixes the problem for more than just PopupPanels. > > However, we think this approach is overkill because the problem really > > doesn't manifest itself in other widgets. > > What about GlassPanel in the Incubator? Sounds like throwing a > GlassPanel into the mix would break things since it isn't a subclass > of PopupPanel and does it's own event previewing. > > > On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> wrote: > > Contributors - > > > > Summary: > > > > In the current implementation of PopupPanel, a PopupPanel with autoHide > > enabled will not autoHide if another Widget (such as another PopupPanel) > > steals the event preview. In practice, this means that if a PopupPanel > is > > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no > > longer autoHide. > > > > Consider an example where you have a SuggestBox inside of a PopupPanel > that > > is autoHide. If you start typing in the SuggestBox, it opens a > PopupPanel > > of suggestions. You then click outside the original popup and expect it > to > > disappear. Instead, only the SuggestBox popup disappears. In this case, > > the PopupPanels are related, but in some cases they are not. If you use > a > > sticky PopupPanel (stays open for a while, ex. a debug menu or log) in > your > > app, it may steal preview from an autoHide PopupPanel, and you have to > close > > one to close the other. > > > > > > Proposed Solution: > > == > > I propose that we add a static stack of PopupPanels to the PopupPanel > > class. As popups are shown and hidden, they are added and removed from > the > > stack. When a popup recieves an event preview, it passes the event down > the > > stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel > that > > is modal. The first modal PopupPanel (which blocks events by definition) > > will end the event preview chain. > > > > > > Example: > > === > > Consider the following stack of PopupPanels, where the top panel is the > last > > one that is opened: > > popup6 (autoHide) > > popup5 > > popup4 (autoHide) > > popup3 (autoHide) > > popup2 (modal) > > popup1 (autoHide) > > popup0 (modal) > > > > Now lets say you click on popup4: > > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. > (NOTE: > > usually, only popup6 gets to preview the event) > > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so > > ignore it. > > 3. Popup4 previews the event. AutoHide is enabled, but the event occured > > over Popup4, so it is ignored. > > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. > > 5. Popup2 previews the event. Modal is enabled, so it ends the chain. > > > > Popup1 and Popup0 never preview the event, so they both remain open. > > > > > > Other Solutions: > > > > We considered passing the event preview down the existing stack of > > EventPreview, which fixes the problem for more than just PopupPanels. > > However, we think this approach is overkill because the problem really > > doesn't manifest itself in other widgets. > > > > Thanks, > > John LaBanca > > [EMAIL PROTECTED] > > > > > > > > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed Modification to PopupPanel
> Other Solutions: > > We considered passing the event preview down the existing stack of > EventPreview, which fixes the problem for more than just PopupPanels. > However, we think this approach is overkill because the problem really > doesn't manifest itself in other widgets. What about GlassPanel in the Incubator? Sounds like throwing a GlassPanel into the mix would break things since it isn't a subclass of PopupPanel and does it's own event previewing. On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> wrote: > Contributors - > > Summary: > > In the current implementation of PopupPanel, a PopupPanel with autoHide > enabled will not autoHide if another Widget (such as another PopupPanel) > steals the event preview. In practice, this means that if a PopupPanel is > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no > longer autoHide. > > Consider an example where you have a SuggestBox inside of a PopupPanel that > is autoHide. If you start typing in the SuggestBox, it opens a PopupPanel > of suggestions. You then click outside the original popup and expect it to > disappear. Instead, only the SuggestBox popup disappears. In this case, > the PopupPanels are related, but in some cases they are not. If you use a > sticky PopupPanel (stays open for a while, ex. a debug menu or log) in your > app, it may steal preview from an autoHide PopupPanel, and you have to close > one to close the other. > > > Proposed Solution: > == > I propose that we add a static stack of PopupPanels to the PopupPanel > class. As popups are shown and hidden, they are added and removed from the > stack. When a popup recieves an event preview, it passes the event down the > stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel that > is modal. The first modal PopupPanel (which blocks events by definition) > will end the event preview chain. > > > Example: > === > Consider the following stack of PopupPanels, where the top panel is the last > one that is opened: > popup6 (autoHide) > popup5 > popup4 (autoHide) > popup3 (autoHide) > popup2 (modal) > popup1 (autoHide) > popup0 (modal) > > Now lets say you click on popup4: > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. (NOTE: > usually, only popup6 gets to preview the event) > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so > ignore it. > 3. Popup4 previews the event. AutoHide is enabled, but the event occured > over Popup4, so it is ignored. > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. > 5. Popup2 previews the event. Modal is enabled, so it ends the chain. > > Popup1 and Popup0 never preview the event, so they both remain open. > > > Other Solutions: > > We considered passing the event preview down the existing stack of > EventPreview, which fixes the problem for more than just PopupPanels. > However, we think this approach is overkill because the problem really > doesn't manifest itself in other widgets. > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Proposed Modification to PopupPanel
Contributors - Summary: In the current implementation of PopupPanel, a PopupPanel with autoHide enabled will not autoHide if another Widget (such as another PopupPanel) steals the event preview. In practice, this means that if a PopupPanel is opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no longer autoHide. Consider an example where you have a SuggestBox inside of a PopupPanel that is autoHide. If you start typing in the SuggestBox, it opens a PopupPanel of suggestions. You then click outside the original popup and expect it to disappear. Instead, only the SuggestBox popup disappears. In this case, the PopupPanels are related, but in some cases they are not. If you use a sticky PopupPanel (stays open for a while, ex. a debug menu or log) in your app, it may steal preview from an autoHide PopupPanel, and you have to close one to close the other. Proposed Solution: == I propose that we add a static stack of PopupPanels to the PopupPanel class. As popups are shown and hidden, they are added and removed from the stack. When a popup recieves an event preview, it passes the event down the stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel that is modal. The first modal PopupPanel (which blocks events by definition) will end the event preview chain. Example: === Consider the following stack of PopupPanels, where the top panel is the last one that is opened: popup6 (autoHide) popup5 popup4 (autoHide) popup3 (autoHide) popup2 (modal) popup1 (autoHide) popup0 (modal) Now lets say you click on popup4: 1. Popup6 previews the event. AutoHide is enabled, so it will hide. (NOTE: usually, only popup6 gets to preview the event) 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so ignore it. 3. Popup4 previews the event. AutoHide is enabled, but the event occured over Popup4, so it is ignored. 4. Popup3 previews the event. AutoHide is enabled, so it will hide. 5. Popup2 previews the event. Modal is enabled, so it ends the chain. Popup1 and Popup0 never preview the event, so they both remain open. Other Solutions: We considered passing the event preview down the existing stack of EventPreview, which fixes the problem for more than just PopupPanels. However, we think this approach is overkill because the problem really doesn't manifest itself in other widgets. Thanks, John LaBanca [EMAIL PROTECTED] --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
On Wed, Dec 3, 2008 at 10:10 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote: > Hey, that's a nice visualization! Using a nice view like that, we can > probably iterate in early 2009 to clean up a lot of this. > Ok, but I do want to create useragent.UserAgent now as I selfishly need the ability to exclude User. Anyone have any objections? > > (Spoiler alert: I'm going to start advocating hard in 2009 to get rid of > module XML altogether and use package and class annotations instead.) > If you need an additional advocate, I'm with you. Knowing that others are interested in doing this makes me very glad I decided not to write my "Modules are broken and encourage bad practices" essay/email. :-) /kel -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4241 - releases/1.6/user/src/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED]
Date: Wed Dec 3 08:53:17 2008
New Revision: 4241
Added:
releases/1.6/user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
(contents, props changed)
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java
Log:
Adds the InlineHyperlink widget, which is just like a Hyperlink, except
that it
isn't wrapped with an outer div, so it lays out inline.
Issue 3056.
patch by: ajr
review by: rjrjr
Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java Wed
Dec 3 08:53:17 2008
@@ -56,17 +56,14 @@
private static HyperlinkImpl impl = GWT.create(HyperlinkImpl.class);
- private Element anchorElem;
+ private final Element anchorElem = DOM.createAnchor();
private String targetHistoryToken;
/**
* Creates an empty hyperlink.
*/
public Hyperlink() {
-setElement(DOM.createDiv());
-DOM.appendChild(getElement(), anchorElem = DOM.createAnchor());
-sinkEvents(Event.ONCLICK);
-setStyleName("gwt-Hyperlink");
+this(DOM.createDiv());
}
/**
@@ -97,6 +94,18 @@
this();
setText(text);
setTargetHistoryToken(targetHistoryToken);
+ }
+
+ protected Hyperlink(Element elem) {
+if (elem == null) {
+ setElement(anchorElem);
+} else {
+ setElement(elem);
+ DOM.appendChild(getElement(), anchorElem);
+}
+
+sinkEvents(Event.ONCLICK);
+setStyleName("gwt-Hyperlink");
}
public HandlerRegistration addClickHandler(ClickHandler handler) {
Added:
releases/1.6/user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
==
--- (empty file)
+++
releases/1.6/user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
Wed Dec 3 08:53:17 2008
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2008 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.user.client.ui;
+
+/**
+ * A widget that serves as an "internal" hyperlink. That is, it is a link
to
+ * another state of the running application. It should behave exactly like
+ * [EMAIL PROTECTED] com.google.gwt.user.client.ui.Hyperlink}, save that it
lays out
+ * as an inline element, not block.
+ *
+ * CSS Style Rules
+ *
+ * .gwt-InlineHyperlink { }
+ *
+ */
+public class InlineHyperlink extends Hyperlink {
+
+ /**
+ * Creates an empty hyperlink.
+ */
+ public InlineHyperlink() {
+super(null);
+
+setStyleName("gwt-InlineHyperlink");
+ }
+
+ /**
+ * Creates a hyperlink with its text and target history token specified.
+ *
+ * @param text the hyperlink's text
+ * @param asHTML true to treat the specified text as html
+ * @param targetHistoryToken the history token to which it will link
+ * @see #setTargetHistoryToken
+ */
+ public InlineHyperlink(String text, boolean asHTML, String
targetHistoryToken) {
+this();
+
+if (asHTML) {
+ setHTML(text);
+} else {
+ setText(text);
+}
+setTargetHistoryToken(targetHistoryToken);
+ }
+
+ /**
+ * Creates a hyperlink with its text and target history token specified.
+ *
+ * @param text the hyperlink's text
+ * @param targetHistoryToken the history token to which it will link
+ */
+ public InlineHyperlink(String text, String targetHistoryToken) {
+this(text, false, targetHistoryToken);
+ }
+}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: small code review: Add InlineHyperlink widget
Thanks for taking a look!
Fixed the nits and committed r4241.
http://codereview.appspot.com/8700/diff/1/3
File user/src/com/google/gwt/user/client/ui/Hyperlink.java (right):
http://codereview.appspot.com/8700/diff/1/3#newcode45
Line 45: * CSS Style Rules .gwt-Hyperlink
{ }
On 2008/12/03 01:40:33, rjrjr wrote:
> Autoformat damage. Please don't autoformat entire existing classes.
Fixed!
http://codereview.appspot.com/8700/diff/1/3#newcode56
Line 56: private Element anchorElem;
On 2008/12/03 01:40:33, rjrjr wrote:
> can you make this final?
Made final!
http://codereview.appspot.com/8700/diff/1/2
File user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
(right):
http://codereview.appspot.com/8700/diff/1/2#newcode25
Line 25: * CSS Style Rules
.gwt-InlineHyperlink { }
On 2008/12/03 01:40:33, rjrjr wrote:
> shouldn't be in one line
Fixed.
http://codereview.appspot.com/8700/diff/1/2#newcode64
Line 64: public InlineHyperlink(String text, String targetHistoryToken)
{
On 2008/12/03 01:40:33, rjrjr wrote:
> I'd expect this to be
> this(text, false, targetHistoryToken);
Good point. Fixed
http://codereview.appspot.com/8700
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: TabPanel feature request
On Wed, Dec 3, 2008 at 1:18 AM, David <[EMAIL PROTECTED]> wrote: > Ray, > > There is already an issue reported do I add a comment or you want me to > create a new issue ? > This is the current reported issue: > http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 > > Will it break so much code when deferring attachment ? > We need to avoid breaking any code. > > I can only speak for my own projects and projects from collegues in the > same company, but I don't see it breaking the existing code. Wouldn't it be > better to put it in a release comment on potential breaking changes and > avoid having a switch that you would like to enable all the time anyway ? I > could certainly be wrong of course. > > PS: is there a way to search in the issues for open issues that have > multiple stars ? It might help in identifying commonly found issues that > should be fixed in short term. It might just be that I will loose my current > job due to offshoring and that would maybe allow me to start contributing - > I am not in a hurry to find a new Job so I want to spend my free time to > improve my understanding. Fixing bugs is always the best way to start > understand code the fullest - and I believe that GWT is great for enterprise > development. > Click the three dots at the right side of the search results to expose the Stars column, and sort by that. > > David > > On Tue, Dec 2, 2008 at 9:58 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > >> The constructor flag is a great idea. David, would you mind logging an >> issue to that effect? >> >> >> On Tue, Dec 2, 2008 at 11:58 AM, David <[EMAIL PROTECTED]> wrote: >> >>> I didn't see any comments... oh, sarcasm =) >>> >>> I'm not going to repeat myself... but there is room for improvement on >>> how bugs and feature requests are treated! >>> >>> >>> Since the TabPanel (really the DeckPanel) currently attaches widgets to the DOM immediately, we might have backward compatibility issues if we attach them lazily. We could make lazy attachment an optional setting though. >>> >>> >>> OK, I understand how that can cause troubles. >>> >>> An alternative that should work for your use case is to use the fact that DeckPanel calls setVisible(true) when a widget is shown (which the LazyPanel exploits to render lazily). You could create your widget in the constructor, but don't attach the inner components to the outermost component until setVisible(true) is called the first time. Then you'd have your widget DOM structure available for manipulation, but you don't pay the render time in the browser. >>> >>> The LazyPanel sounds like a workable solution, if I am the only developer >>> in the team and/or everything is in one big project. But that is not the >>> case, I do not have control on how they are using it. I could document it as >>> a workaround, but still everybody who uses a TabPanel in which they might >>> use one of these widgets (somewhere hidden in a Composite panel) must >>> implement the workaround. There must be a solution that would avoid the need >>> for workarounds - it just moves complications to all the users of a >>> component and becomes a maintenance problem in the end. >>> >>> A flag on the TabPanel/DeckPanel would be a better solution, I would just >>> subclass and make sure that the lazy attachment is used on all our panels. >>> That I could get away with, but still I find it a pitty that it is not the >>> default behaviour. >>> >>> >>> David >>> On Tue, Dec 2, 2008 at 3:04 AM, stuckagain <[EMAIL PROTECTED]>wrote: > > Thanks for the great comments! > > It turns out that this bug is already reported (and 5 stars as well) > in the issue database. > jlaba is the owner of the bug and priority is medium > > Here is the bug report: > http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 > > David > > On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: > > People, > > > > I recently read about lazy loading panels > http://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio. > .. > > > > I am actually asking for offering lazy attaching tabpanels as a > > default implementation. In most cases you only get a > > performance problem when you attach the Widgets to the DOM tree, > > creating the UI without attaching is done in milliseconds. > > > > In case of a TabPabel it can sometimes be very cumbersome to use lazy > > loading for the different tabs. Loading it lazily is easy, but > > gathering information from multiple tabs to post to the server must > > take into account that maybe the widgets are null... that makes the > > code much more complicated than it should be. > > > > By deferring attaching to the DOM tree until first shown, all this is > > not needed. Creating the widgets is most of the time very fas
[gwt-contrib] [google-web-toolkit commit] r4240 - trunk/tools/soyc-vis
Author: [EMAIL PROTECTED] Date: Wed Dec 3 08:28:14 2008 New Revision: 4240 Modified: trunk/tools/soyc-vis/build.xml Log: Added dummy test and checkstyle targets so that the build does not break. Patch by: kprobst Review by: amitmanjhi Modified: trunk/tools/soyc-vis/build.xml == --- trunk/tools/soyc-vis/build.xml (original) +++ trunk/tools/soyc-vis/build.xml Wed Dec 3 08:28:14 2008 @@ -13,5 +13,9 @@ + + + + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding .project to gwt-incubator root directory
By the way, if anyone has any problems with the new structure, , please file a bug under gwt-incubator's bug tracker. If the instructions are not clear on the incubator wiki( http://code.google.com/p/google-web-toolkit-incubator/wiki/WorkingWithEclipse), please add a comment under the wiki. Thanks! Emily On Mon, Dec 1, 2008 at 2:14 PM, Arthur Kalmenson <[EMAIL PROTECTED]>wrote: > > We check the .project file in for all of our projects, this makes > picking it up from the repo really easy. > > -- > Arthur Kalmenson > > > > On Mon, Nov 24, 2008 at 11:31 AM, Lex Spoon <[EMAIL PROTECTED]> wrote: > > > > On Mon, Nov 17, 2008 at 4:28 PM, BobV <[EMAIL PROTECTED]> wrote: > >> > >>> What exactly is the reason we can't do the same here? > >> > >> subclipse won't handle linked resources. > > > > Seconded. Saying that the trunk arrangement "works" is a mild > overstatement. > > > > That said, I don't know if there is some way to make an eclipse > > subdirectory work or not. It might be possible if the linked > > resources can be avoided. Still, checking in the .project file works > > fine as far as I know. I've worked on projects that did so before. > > > > > > -Lex > > > > > > > > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
+1 On 12/3/08, Bruce Johnson <[EMAIL PROTECTED]> wrote: > Hey, that's a nice visualization! Using a nice view like that, we can > probably iterate in early 2009 to clean up a lot of this. > (Spoiler alert: I'm going to start advocating hard in 2009 to get rid of > module XML altogether and use package and class annotations instead.) > > On Wed, Dec 3, 2008 at 9:00 AM, Kelly Norton <[EMAIL PROTECTED]> wrote: > >> btw, Attached is a morbid look at the dependency graph starting from >> user.User. >> /kel >> >> On Wed, Dec 3, 2008 at 8:50 AM, <[EMAIL PROTECTED]> wrote: >> >>> I'm going to add useragent.UserAgent and update a new patch. >>> /kel >>> >>> On 2008/12/03 12:50:52, knorton wrote: >>> Thanks for looking at this Thomas, Maybe UserAgent should just go into a path that has no client source >>> associated >>> with it. That would provide fine grain inheritance. But before we do >>> do that, >>> would it be reasonable in your uses to just inherit dom.Dom? For all my uses this seemed reasonable. This still means that >>> UserAgent is not >>> independently inheritable, but that is a big issue that we have all >>> over the >>> place. We've done an extremely poor job of separating those modules >>> that are >>> setup to be inherited and those that just group some deferred binding >>> rules. In >>> fact, most of the modules in User cannot be inherited by themselves. To be honest, I wish we would start creating larger .gwt.xml files and >>> make each >>> one that exists inheritable. Doing that would mean that I would get >>> rid of >>> UserAgent.gwt.xml altogether and move its contents into >>> dom.DOM.gwt.xml. (or >>> either create useragent.UserAgent.gwt.xml) So, I'm not opposed to making useragent.UserAgent. But I would like to >>> try to >>> just make UserAgent be a part of DOM if that is at all feasible. >>> >>> >>> http://gwt-code-reviews.appspot.com/401 >>> >> >> >> >> -- >> If you received this communication by mistake, you are entitled to one >> free >> ice cream cone on me. Simply print out this email including all relevant >> SMTP headers and present them at my desk to claim your creamy treat. We'll >> have a laugh at my emailing incompetence, and play a game of ping pong. >> (offer may not be valid in all States). >> >> > >> > > > > -- Fred Sauer [EMAIL PROTECTED] --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Datepicker: Global style v. visible style
On Wed, Dec 3, 2008 at 6:46 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > Let us say you have a ui design where every-other day is styled a different > color and that we only have global styles available. > > Now, the "correct" way to do this is for the user to add the styles to each > day of each month. The problem, of course, is that we as library designers > do not know how many months the application designer anticipates their user > trolling through, and for each day in each month in each year we will end up > accumulating global state. I see. I'll punch up the javadoc. Now recently, as a team, we have been moving to a model where we care a lot > less about memory efficiency, so we can use that argument to change the > design and remove the visible date mechanics. Editorial noted, and disagreed with. > > > Cheers, > > Emily > > > > > > On Tue, Dec 2, 2008 at 9:03 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > >> I'm working through the big date picker review: >> >> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/486babc9bb0863a9 >> >> I don't understand why we provide addGlobalStyleToDateand >> addStyleToVisibleDates, especially since the latter will explode in your >> face if you call it on an invisible date, except when it doesn't in web >> mode. >> >> Why don't we get rid of the visibleDate variants, and drop the "global" >> from the others? >> >> rjrjr >> >> > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
Hey, that's a nice visualization! Using a nice view like that, we can probably iterate in early 2009 to clean up a lot of this. (Spoiler alert: I'm going to start advocating hard in 2009 to get rid of module XML altogether and use package and class annotations instead.) On Wed, Dec 3, 2008 at 9:00 AM, Kelly Norton <[EMAIL PROTECTED]> wrote: > btw, Attached is a morbid look at the dependency graph starting from > user.User. > /kel > > On Wed, Dec 3, 2008 at 8:50 AM, <[EMAIL PROTECTED]> wrote: > >> I'm going to add useragent.UserAgent and update a new patch. >> /kel >> >> On 2008/12/03 12:50:52, knorton wrote: >> >>> Thanks for looking at this Thomas, >>> Maybe UserAgent should just go into a path that has no client source >>> >> associated >> >>> with it. That would provide fine grain inheritance. But before we do >>> >> do that, >> >>> would it be reasonable in your uses to just inherit dom.Dom? >>> >>> For all my uses this seemed reasonable. This still means that >>> >> UserAgent is not >> >>> independently inheritable, but that is a big issue that we have all >>> >> over the >> >>> place. We've done an extremely poor job of separating those modules >>> >> that are >> >>> setup to be inherited and those that just group some deferred binding >>> >> rules. In >> >>> fact, most of the modules in User cannot be inherited by themselves. >>> >>> To be honest, I wish we would start creating larger .gwt.xml files and >>> >> make each >> >>> one that exists inheritable. Doing that would mean that I would get >>> >> rid of >> >>> UserAgent.gwt.xml altogether and move its contents into >>> >> dom.DOM.gwt.xml. (or >> >>> either create useragent.UserAgent.gwt.xml) >>> >>> So, I'm not opposed to making useragent.UserAgent. But I would like to >>> >> try to >> >>> just make UserAgent be a part of DOM if that is at all feasible. >>> >> >> >> http://gwt-code-reviews.appspot.com/401 >> > > > > -- > If you received this communication by mistake, you are entitled to one free > ice cream cone on me. Simply print out this email including all relevant > SMTP headers and present them at my desk to claim your creamy treat. We'll > have a laugh at my emailing incompetence, and play a game of ping pong. > (offer may not be valid in all States). > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4235.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4235. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4235 Score: Positive General Comment: LGTM Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4235 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: TBR review needed on r4235 (date picker branch)
LGTM On Tue, Dec 2, 2008 at 7:09 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Tweaks in response to review of r4188. Use Labels instead of TextBoxes in > examples, and explain use of VerticalPanel in DatePicker. > > http://code.google.com/p/google-web-toolkit/source/detail?r=4235 > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4239.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4239. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4239 Score: Positive General Comment: LGTM Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4239 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Datepicker: Global style v. visible style
Let us say you have a ui design where every-other day is styled a different color and that we only have global styles available. Now, the "correct" way to do this is for the user to add the styles to each day of each month. The problem, of course, is that we as library designers do not know how many months the application designer anticipates their user trolling through, and for each day in each month in each year we will end up accumulating global state. Now recently, as a team, we have been moving to a model where we care a lot less about memory efficiency, so we can use that argument to change the design and remove the visible date mechanics. Cheers, Emily On Tue, Dec 2, 2008 at 9:03 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > I'm working through the big date picker review: > > http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/486babc9bb0863a9 > > I don't understand why we provide addGlobalStyleToDateand > addStyleToVisibleDates, especially since the latter will explode in your > face if you call it on an invisible date, except when it doesn't in web > mode. > > Why don't we get rid of the visibleDate variants, and drop the "global" > from the others? > > rjrjr > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
I'm going to add useragent.UserAgent and update a new patch. /kel On 2008/12/03 12:50:52, knorton wrote: > Thanks for looking at this Thomas, > Maybe UserAgent should just go into a path that has no client source associated > with it. That would provide fine grain inheritance. But before we do do that, > would it be reasonable in your uses to just inherit dom.Dom? > > For all my uses this seemed reasonable. This still means that UserAgent is not > independently inheritable, but that is a big issue that we have all over the > place. We've done an extremely poor job of separating those modules that are > setup to be inherited and those that just group some deferred binding rules. In > fact, most of the modules in User cannot be inherited by themselves. > > To be honest, I wish we would start creating larger .gwt.xml files and make each > one that exists inheritable. Doing that would mean that I would get rid of > UserAgent.gwt.xml altogether and move its contents into dom.DOM.gwt.xml. (or > either create useragent.UserAgent.gwt.xml) > > So, I'm not opposed to making useragent.UserAgent. But I would like to try to > just make UserAgent be a part of DOM if that is at all feasible. http://gwt-code-reviews.appspot.com/401 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
On Wed, Dec 3, 2008 at 8:18 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote: > On Wed, Dec 3, 2008 at 7:50 AM, <[EMAIL PROTECTED]> wrote: > >> To be honest, I wish we would start creating larger .gwt.xml files and >> make each one that exists inheritable. > > > I agree. It was a rookie decision we made early on to over-emphasize > fine-grained module reuse, and, like C header files, nobody has enough > discipline (or incentive) to ensure they are all truly independently > inheritable. > A good question is whether we can just change it. The way things are currently, you can't inherit any submodule out of user without getting all of User. You either get errors because you are picking up gunk out of client that doesn't appear to be translatable or you include one of the few modules with a circular reference (SplitPanel or Animation). So given that you can't inherit them now, could we just delete the submodules and inline their contents into User? The only danger is that someone may've have done this: or // not realizing that it loops back to pick up all of User So removing DOM.gwt.xml would produce an error for those clients. > > >> Doing that would mean that I >> would get rid of UserAgent.gwt.xml altogether and move its contents into >> dom.DOM.gwt.xml. (or either create useragent.UserAgent.gwt.xml) > > > The reason not to do this would be if there are other important use cases > of modules that switch on User Agent but don't use DOM. I can only think of > one right now: StringBuidler in 1.6 is the first place where the JRE can be > sensitive to user agent. And you *might* in theory want to do sheer > computation in GWT without touching the DOM (e.g. in a Gears worker thread). > > If we're going to make this kind of change, perhaps we should debate the > merits of useragent.UserAgent to be darn sure it isn't the better option. > This is enough of an argument to make me a supporter of useragent.UserAgent. Now that you mention it, we have already tried to position it as an independently inheritable module when we introduced UserAgent JRE optimizations. /kel -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
On Wed, Dec 3, 2008 at 7:50 AM, <[EMAIL PROTECTED]> wrote: > To be honest, I wish we would start creating larger .gwt.xml files and > make each one that exists inheritable. I agree. It was a rookie decision we made early on to over-emphasize fine-grained module reuse, and, like C header files, nobody has enough discipline (or incentive) to ensure they are all truly independently inheritable. > Doing that would mean that I > would get rid of UserAgent.gwt.xml altogether and move its contents into > dom.DOM.gwt.xml. (or either create useragent.UserAgent.gwt.xml) The reason not to do this would be if there are other important use cases of modules that switch on User Agent but don't use DOM. I can only think of one right now: StringBuidler in 1.6 is the first place where the JRE can be sensitive to user agent. And you *might* in theory want to do sheer computation in GWT without touching the DOM (e.g. in a Gears worker thread). If we're going to make this kind of change, perhaps we should debate the merits of useragent.UserAgent to be darn sure it isn't the better option. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
Thanks for looking at this Thomas, Maybe UserAgent should just go into a path that has no client source associated with it. That would provide fine grain inheritance. But before we do do that, would it be reasonable in your uses to just inherit dom.Dom? For all my uses this seemed reasonable. This still means that UserAgent is not independently inheritable, but that is a big issue that we have all over the place. We've done an extremely poor job of separating those modules that are setup to be inherited and those that just group some deferred binding rules. In fact, most of the modules in User cannot be inherited by themselves. To be honest, I wish we would start creating larger .gwt.xml files and make each one that exists inheritable. Doing that would mean that I would get rid of UserAgent.gwt.xml altogether and move its contents into dom.DOM.gwt.xml. (or either create useragent.UserAgent.gwt.xml) So, I'm not opposed to making useragent.UserAgent. But I would like to try to just make UserAgent be a part of DOM if that is at all feasible. http://gwt-code-reviews.appspot.com/401 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] t.broyer commented on revision r4225.
[google-web-toolkit] t.broyer commented on revision r4225. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4225 Score: Neutral General Comment: Same comment as for r4098 and r4122 on KeyEvent.isAnyModifierKeyDown initial implementations. Why calling all getXXXKey up-front? Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4225 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Breaks dom.DOM dependency on user.UserAgent
I'd rather put it elsewhere, as it would just move the problem but not solve issue 2815. http://code.google.com/p/google-web-toolkit/issues/detail?id=2815 http://gwt-code-reviews.appspot.com/401 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: TabPanel feature request
Ray, There is already an issue reported do I add a comment or you want me to create a new issue ? This is the current reported issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 Will it break so much code when deferring attachment ? I can only speak for my own projects and projects from collegues in the same company, but I don't see it breaking the existing code. Wouldn't it be better to put it in a release comment on potential breaking changes and avoid having a switch that you would like to enable all the time anyway ? I could certainly be wrong of course. PS: is there a way to search in the issues for open issues that have multiple stars ? It might help in identifying commonly found issues that should be fixed in short term. It might just be that I will loose my current job due to offshoring and that would maybe allow me to start contributing - I am not in a hurry to find a new Job so I want to spend my free time to improve my understanding. Fixing bugs is always the best way to start understand code the fullest - and I believe that GWT is great for enterprise development. David On Tue, Dec 2, 2008 at 9:58 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > The constructor flag is a great idea. David, would you mind logging an > issue to that effect? > > > On Tue, Dec 2, 2008 at 11:58 AM, David <[EMAIL PROTECTED]> wrote: > >> >>> I didn't see any comments... oh, sarcasm =) >>> >> >> I'm not going to repeat myself... but there is room for improvement on how >> bugs and feature requests are treated! >> >> >> >>> Since the TabPanel (really the DeckPanel) currently attaches widgets to >>> the DOM immediately, we might have backward compatibility issues if we >>> attach them lazily. We could make lazy attachment an optional setting >>> though. >> >> >> OK, I understand how that can cause troubles. >> >> An alternative that should work for your use case is to use the fact that >>> DeckPanel calls setVisible(true) when a widget is shown (which the LazyPanel >>> exploits to render lazily). You could create your widget in the >>> constructor, but don't attach the inner components to the outermost >>> component until setVisible(true) is called the first time. Then you'd have >>> your widget DOM structure available for manipulation, but you don't pay the >>> render time in the browser. >>> >> >> The LazyPanel sounds like a workable solution, if I am the only developer >> in the team and/or everything is in one big project. But that is not the >> case, I do not have control on how they are using it. I could document it as >> a workaround, but still everybody who uses a TabPanel in which they might >> use one of these widgets (somewhere hidden in a Composite panel) must >> implement the workaround. There must be a solution that would avoid the need >> for workarounds - it just moves complications to all the users of a >> component and becomes a maintenance problem in the end. >> >> A flag on the TabPanel/DeckPanel would be a better solution, I would just >> subclass and make sure that the lazy attachment is used on all our panels. >> That I could get away with, but still I find it a pitty that it is not the >> default behaviour. >> >> >> David >> >>> >>> On Tue, Dec 2, 2008 at 3:04 AM, stuckagain <[EMAIL PROTECTED]>wrote: >>> Thanks for the great comments! It turns out that this bug is already reported (and 5 stars as well) in the issue database. jlaba is the owner of the bug and priority is medium Here is the bug report: http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 David On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: > People, > > I recently read about lazy loading panels http://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio. .. > > I am actually asking for offering lazy attaching tabpanels as a > default implementation. In most cases you only get a > performance problem when you attach the Widgets to the DOM tree, > creating the UI without attaching is done in milliseconds. > > In case of a TabPabel it can sometimes be very cumbersome to use lazy > loading for the different tabs. Loading it lazily is easy, but > gathering information from multiple tabs to post to the server must > take into account that maybe the widgets are null... that makes the > code much more complicated than it should be. > > By deferring attaching to the DOM tree until first shown, all this is > not needed. Creating the widgets is most of the time very fast, it is > only when they get attached that the Browser shokes. When I was > experimenting with tables in IE6 for example, I could build up a table > of 250 rows in memory in a few milliseconds, but as soon as I attached > the table, I lost 8 seconds that the Browser was not responsive. > > So,... anybody cares about the sub
