[gwt-contrib] Re: Code Review: Updated SliderBar to use the new event handling
LGTM On Mon, Mar 2, 2009 at 7:49 AM, Uwe Maurer uwe.mau...@google.com wrote: Hi, I moved the SliderBar to com.google.gwt.gen2.picker.client package, and the demo to the corresponding package. I added methods to use the new event handling to the Slider Bar, and removed the old event methods. I added style injection via Gen2CssInjector. (and added the images and css to com.google/gwt/gen2/widgetbase/public) The patch is in the attached file. Thanks, Uwe On Fri, Feb 27, 2009 at 5:13 PM, Emily Crutcher e...@google.com wrote: The changes look great. Thank you for doing this. Any chance you could you create a gen2 version of SliderBar and deprecate the widgetideas version instead on modifying the widgetideas version in place? We are slowly retiring the old widgetideas package in favor of the gen2 package hierarchy, so every time we would have to make a breaking API change to a widgetideas widget, we try to deprecate the old one and move the new one into a gen2 package instead. In this case, as the slider is a way to pick a value from a range, it would go into the gen2.picker.client package. Cheers, Emily On Fri, Feb 27, 2009 at 10:32 AM, Uwe Maurer uwe.mau...@google.com wrote: Hi, I added methods to use the new event handling to the Slider Bar. Also I changed to order of the two public interfaces to make CheckStyle happy. Thanks, Uwe -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: Updated SliderBar to use the new event handling
The changes look great. Thank you for doing this. Any chance you could you create a gen2 version of SliderBar and deprecate the widgetideas version instead on modifying the widgetideas version in place? We are slowly retiring the old widgetideas package in favor of the gen2 package hierarchy, so every time we would have to make a breaking API change to a widgetideas widget, we try to deprecate the old one and move the new one into a gen2 package instead. In this case, as the slider is a way to pick a value from a range, it would go into the gen2.picker.client package. Cheers, Emily On Fri, Feb 27, 2009 at 10:32 AM, Uwe Maurer uwe.mau...@google.com wrote: Hi, I added methods to use the new event handling to the Slider Bar. Also I changed to order of the two public interfaces to make CheckStyle happy. Thanks, Uwe -- 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: Make DateBox fire ValueChangeEvent more reliably.
Thanks for the fast turn around, committed as r4898 2009/2/27 jlaba...@google.com LGTM http://gwt-code-reviews.appspot.com/7804 -- 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: Fixes Issue 3378, adding protected getHandlerCount() to widget.
Committed at r4885 On Tue, Feb 24, 2009 at 6:16 PM, Ray Ryan rj...@google.com wrote: LGTM Nah, just rename and submit. On Tue, Feb 24, 2009 at 3:13 PM, Emily Crutcher e...@google.com wrote: Hmm Any reasons I can think of dissolve under the argument of that what I'd look for. Do you want a new patch with the rename? On Tue, Feb 24, 2009 at 6:08 PM, rj...@google.com wrote: Thanks for the quick response. Only one nit: why not just call the test WidgetTest? That's certainly what I'd look for when I wanted to extend it. http://gwt-code-reviews.appspot.com/7802 -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Associating Data Transfer Objects (DTOs) with Suggestion Objects
It could work, though I found when I used this technique with DatePicker (DatePicker extends AbstractDatePickerMonthSelector, CalandarView), there was some feedback that having that abstract type layer was slightly confusing because good OO practice implied that references should then be typed as AbstractDatePicker, which then brought in the complexity of the generic types back into the lives of the 90% who did not care about the parameterized arguments. On Tue, Feb 24, 2009 at 10:00 AM, Ray Ryan rj...@google.com wrote: How about extracting a parameterized super class: AbstractSuggestionBoxT extends Suggestion SuggestionBox extends AbstractSuggestionBoxSuggestion rjrjr On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher e...@google.com wrote: On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett itru...@gmail.com wrote: The API documentation has this to say on the subject: [...] To send back a DTO with each suggestion, extend the Suggestion interface and define a getter method that has a return value of the DTO's type. Define a class that implements this subinterface and use it to encapsulate each suggestion. To access a suggestion's DTO when the suggestion is selected, add a SuggestionHandler to the SuggestBox (see SuggestBox's documentation for more information). In the SuggestionHandler.onSuggestionSelected(SuggestionEvent event) method, obtain the selected Suggestion object from the SuggestionEvent object, and downcast the Suggestion object to the subinterface. Then, acces the DTO using the DTO getter method that was defined on the subinterface. See http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/SuggestOracle.Suggestion.html (the 1.6 version is similar, but with the new event model) So the endorsed solution is to extend and cast. Fair enough. This probably dates from pre-1.5, and it was good enough for then. But is there a reason not to parameterize SuggestBox with T extends Suggestion (and SuggestOracleT, SelectionEventT, etc.) now that that's an option? Or perhaps make Suggestion implement HasValueT? I have an application that uses many SuggestBoxes and many different Suggestion subclasses and this would simplify things (and eliminate much type-casting). I'm not sure parameterizing SuggestBox itself would be worth it, as most people use it without creating new types of suggestions: so the parameterization would add clutter for the many and prevent casts for the few. Though, I completely agree it is annoying to have to cast. Perhaps we could create a composite-based CustomSuggestBox that is parameterized? Any thoughts on this? Horrible side effects that I'm missing? - Isaac -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Associating Data Transfer Objects (DTOs) with Suggestion Objects
If that concern doesn't seem like it would be a problem, then I definitely agree with you that creating abstract base classes that have the parametrized types seems like the best solution. On Tue, Feb 24, 2009 at 10:54 AM, Ray Ryan rj...@google.com wrote: That feedback sounds a bit pedantic and impractical to me. And my job title used to be Senior Pedant. On Tue, Feb 24, 2009 at 7:44 AM, Emily Crutcher e...@google.com wrote: It could work, though I found when I used this technique with DatePicker (DatePicker extends AbstractDatePickerMonthSelector, CalandarView), there was some feedback that having that abstract type layer was slightly confusing because good OO practice implied that references should then be typed as AbstractDatePicker, which then brought in the complexity of the generic types back into the lives of the 90% who did not care about the parameterized arguments. On Tue, Feb 24, 2009 at 10:00 AM, Ray Ryan rj...@google.com wrote: How about extracting a parameterized super class: AbstractSuggestionBoxT extends Suggestion SuggestionBox extends AbstractSuggestionBoxSuggestion rjrjr On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher e...@google.com wrote: On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett itru...@gmail.comwrote: The API documentation has this to say on the subject: [...] To send back a DTO with each suggestion, extend the Suggestion interface and define a getter method that has a return value of the DTO's type. Define a class that implements this subinterface and use it to encapsulate each suggestion. To access a suggestion's DTO when the suggestion is selected, add a SuggestionHandler to the SuggestBox (see SuggestBox's documentation for more information). In the SuggestionHandler.onSuggestionSelected(SuggestionEvent event) method, obtain the selected Suggestion object from the SuggestionEvent object, and downcast the Suggestion object to the subinterface. Then, acces the DTO using the DTO getter method that was defined on the subinterface. See http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/SuggestOracle.Suggestion.html (the 1.6 version is similar, but with the new event model) So the endorsed solution is to extend and cast. Fair enough. This probably dates from pre-1.5, and it was good enough for then. But is there a reason not to parameterize SuggestBox with T extends Suggestion (and SuggestOracleT, SelectionEventT, etc.) now that that's an option? Or perhaps make Suggestion implement HasValueT? I have an application that uses many SuggestBoxes and many different Suggestion subclasses and this would simplify things (and eliminate much type-casting). I'm not sure parameterizing SuggestBox itself would be worth it, as most people use it without creating new types of suggestions: so the parameterization would add clutter for the many and prevent casts for the few. Though, I completely agree it is annoying to have to cast. Perhaps we could create a composite-based CustomSuggestBox that is parameterized? Any thoughts on this? Horrible side effects that I'm missing? - Isaac -- 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't -- 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: review for issue 249 fix
Thanks for the quick turn around! commited at r4853 2009/2/24 rj...@google.com LGTM http://gwt-code-reviews.appspot.com/7801 -- 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: Associating Data Transfer Objects (DTOs) with Suggestion Objects
On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett itru...@gmail.com wrote: The API documentation has this to say on the subject: [...] To send back a DTO with each suggestion, extend the Suggestion interface and define a getter method that has a return value of the DTO's type. Define a class that implements this subinterface and use it to encapsulate each suggestion. To access a suggestion's DTO when the suggestion is selected, add a SuggestionHandler to the SuggestBox (see SuggestBox's documentation for more information). In the SuggestionHandler.onSuggestionSelected(SuggestionEvent event) method, obtain the selected Suggestion object from the SuggestionEvent object, and downcast the Suggestion object to the subinterface. Then, acces the DTO using the DTO getter method that was defined on the subinterface. See http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/SuggestOracle.Suggestion.html (the 1.6 version is similar, but with the new event model) So the endorsed solution is to extend and cast. Fair enough. This probably dates from pre-1.5, and it was good enough for then. But is there a reason not to parameterize SuggestBox with T extends Suggestion (and SuggestOracleT, SelectionEventT, etc.) now that that's an option? Or perhaps make Suggestion implement HasValueT? I have an application that uses many SuggestBoxes and many different Suggestion subclasses and this would simplify things (and eliminate much type-casting). I'm not sure parameterizing SuggestBox itself would be worth it, as most people use it without creating new types of suggestions: so the parameterization would add clutter for the many and prevent casts for the few. Though, I completely agree it is annoying to have to cast. Perhaps we could create a composite-based CustomSuggestBox that is parameterized? Any thoughts on this? Horrible side effects that I'm missing? - Isaac -- 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: RR (incubator): Color constructor operator order
LGTM, thanks for the terrific turn around time! On Mon, Feb 9, 2009 at 9:43 AM, Jaime Yap jaime...@google.com wrote: Super simple fix. Had the order of operators swapped in one of the constructor overloads for Color. Affected files: src/com/google/gwt/widgetideas/graphics/client/Color.java -Jaime -- 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: RR : Declassifying RPC / Removing all type names from compilation
branch to check the -XdisableClassMetadata flag. @ecc, this reduces showcase by about 10%. I would suspect that in an RPC-heavy application, this flag combined with enabling obfuscated idents in RPC payloads, should produce similar savings. WOOT! -- Bob Vawter Google Web Toolkit Team -- 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: RR : Declassifying RPC / Removing all type names from compilation
Do you have any numbers of how much this shrinks compiled output, as this seems like a terrific change! Thanks for doing it :-). Cheers, Emily On Fri, Feb 6, 2009 at 1:21 PM, BobV b...@google.com wrote: On Thu, Feb 5, 2009 at 12:28 AM, BobV b...@google.com wrote: http://google-web-toolkit.googlecode.com/svn/changes/bobv/elide_rpc_type_names_r4602 Future changes: - A compiler flag or optional module to neuter Class.getName(). I've added an -XdisableClassMetadata flag to this branch. This disables: - Class.getName() - returns Class$hashCode() - Class.getSuperclass() - returns null - Class.toString() - returns Object.toString() You can still use class.getName() as an equality comparison, but not for anything that requires semantic meaning; the relationships between the strings will be constant throughout the lifetime of the module. A.class == A.class != B.class A.class.getName() == A.class.getName() != B.class.getName() With this flag enabled, class literal setup for non-enum types is a simple JS new operation. It reduces the total amount of code generated in a showcase compile by 10% based on find war -name '*.cache.html' -o -name '*.cache.js' | xargs wc. -- Bob Vawter Google Web Toolkit Team -- 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: Announcing GWT 1.6 Milestone 1
Only the current gwt-incubator trunk is validated to work against the release jar. We'll be releasing a new gwt-incubator jar soon, but I'm still working on getting all the demos to build and display correctly. On Thu, Feb 5, 2009 at 12:24 PM, Scott Blum sco...@google.com wrote: Hi stuckagain, It looks like you are using a version of the incubator jar that is not compatible with the milestone build. Can you start a new thread about that and CC e...@google.com? I'm not sure why the compiler is trying to load gwt-ll, I will check it out, thanks. Scott -- 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: Image doesn’t show when using sa me URL multiple times and using the new event system
Can you create a test case that is reproducible and add an issue to the issue tracker? After you do that, feel free to e-mail me the issue id and I'll take a look. The strange thing about your problem is that the load listeners are actually just adapted load handlers now, so getting different behavior is pretty unexpected. On Thu, Feb 5, 2009 at 1:21 PM, aris ari09845...@gmail.com wrote: Is any one having this problem? I just installed the latest version and I have the same problem. If I add a random number to each call of each url, it works. But of course this is not a real solution… Thanks -- 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 -~--~~~~--~~--~--~---
Re: tree item selection issue- removing the box
I was using the FastTree widget, not the Tree widget unfortunately. Try googling for selection box, highlight box, focus box. All the browsers useslightly different ways of removing that box. However, it is such a pain to remove, that you might be better off figuring out a way to use different css for your tree. On Wed, Feb 4, 2009 at 11:43 AM, Jill Singer jillre...@alum.mit.edu wrote: in both firefox and ie, when I click on a tree item a dotted box is put around the selection. since I am using a static positioning (see http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/71349ea300afaa88 ) the dotted box is offset from the actual selection, and is thus disorienting. I would like to remove that box; I have been using firebug to hunt down the style I need to change, without any results. I found this thread; which says it can be done but doesn't offer any solutions: Emily Crutcher wrote here: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/a63a973ee627dded I noticed a few styling issues: - Firefox puts a box around the selected tree item (see attached image). Can it be removed? Yes. any one know how to do this? thanks -Jill -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
[gwt-contrib] Re: FastTree gen2 tweaks
On Wed, Feb 4, 2009 at 10:02 AM, nw...@google.com wrote:
looks great, thanks for doing this. I have one minor question/comment.
http://gwt-code-reviews.appspot.com/2801/diff/1/7
File src/com/google/gwt/gen2/widgetbase/public/FastTree.css (right):
http://gwt-code-reviews.appspot.com/2801/diff/1/7#newcode66
Line 66: background: #e3e8f3 url('%selectionBar%') repeat-x;
this is the only thing that confuses me, are we no longer injecting the
images? (as you're doing for the open/close gif's) and if so are we
still injecting the selectionBar image?
That one should be changed to, thanks for spottint it. We want to inject
images again, but that should be part of an end-to-end css solution for
widgets. Will change it and commit.
http://gwt-code-reviews.appspot.com/2801
--
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] after the fact code review: bumping up stack needed by gwt incubator's test suite:
Here is the change: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1466 -- 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: DropDownListBox upgrade
Committed as r1467 On Mon, Feb 2, 2009 at 6:08 PM, Emily Crutcher e...@google.com wrote: Yep, thanks for the review! On Mon, Feb 2, 2009 at 5:46 PM, itru...@gmail.com wrote: LGTM, with the removal of stray debug code from DropDownPanel. http://gwt-code-reviews.appspot.com/2402/diff/1/10 File src/com/google/gwt/gen2/commonwidget/client/DropDownPanel.java (right): http://gwt-code-reviews.appspot.com/2402/diff/1/10#newcode37 Line 37: static int fool; Is this debugging code that didn't get removed? http://gwt-code-reviews.appspot.com/2402 -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: after the fact code review: bumping up stack needed by gwt incubator's test suite:
For the heap, I think that would be a good change. The stack though in
general, is not something programs should have to mess with.
On Tue, Feb 3, 2009 at 11:59 AM, Freeland Abbott gwt.team.fabb...@gmail.com
wrote:
Looks good, but can we make heap and stack be parameters to gwt.junit? For
incubator it may not matter, but when you have a second suite you may want
different memory profiles in each.
Something like:
*macrodef name=gwt.junit
...
**attribute name=jvm.heap default=512M /
** **attribute name=jvm.stack default=1M /*
...
* **jvmarg line=-...@{jvm.heap} -x...@{jvm.stack} /
...
*and then each use can set its own limits, like so:*
gwt.junit jvm.heap=1G jvm.stack=256K ... /
*
On Tue, Feb 3, 2009 at 11:53 AM, Emily Crutcher e...@google.com wrote:
Here is the change:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1466
--
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't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: after the fact code review: bumping up stack needed by gwt incubator's test suite:
Adding heap param:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1468
The difference is with heap, the amount of memory is proportional to the
size of the tests and has a significant cost to set to high.
With stack, the size is proportional to nothing user visible, just a matter
of how the gwt serialization happened to work, and the number does not
effect performance in any significant way.
On Tue, Feb 3, 2009 at 12:38 PM, Freeland Abbott gwt.team.fabb...@gmail.com
wrote:
I'll LGTM either way, since you've only got one test anyway... but in GWT
projects, I've seen more than one stack change required recently.
On Tue, Feb 3, 2009 at 12:33 PM, Emily Crutcher e...@google.com wrote:
For the heap, I think that would be a good change. The stack though in
general, is not something programs should have to mess with.
On Tue, Feb 3, 2009 at 11:59 AM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Looks good, but can we make heap and stack be parameters to gwt.junit?
For incubator it may not matter, but when you have a second suite you may
want different memory profiles in each.
Something like:
*macrodef name=gwt.junit
...
**attribute name=jvm.heap default=512M /
** **attribute name=jvm.stack default=1M /*
...
* **jvmarg line=-...@{jvm.heap} -x...@{jvm.stack} /
...
*and then each use can set its own limits, like so:*
gwt.junit jvm.heap=1G jvm.stack=256K ... /
*
On Tue, Feb 3, 2009 at 11:53 AM, Emily Crutcher e...@google.com wrote:
Here is the change:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1466
--
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't
--
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: IE6 and Grid Performance
One warning for you, the performance characteristics of having a grid be attached or detached can be very different for Firefox and IE. If you are trying to use this technique in your own code, you might want to double check the effect on both browsers. In terms of gwt-incubator, we are brainstorming on ways to let our users know which widgets/libraries are relatively stable (if they were perfectly stable they would have graduated already) and which are still wildly fluctuating, once we have a proposal, I will be sending it out on this list, so stay tuned. Even for relatively stable widgets though, I think having a facade around them is probably the smartest way to use them, so I'm glad your group is using that practice. Cheers, Emily On Tue, Feb 3, 2009 at 2:45 PM, David david.no...@gmail.com wrote: Hi John, I know about incubator and we are using PagingScrollTable in other places where the data can be much bigger. But the point that I was trying to report: some operations that do bulk operations in the Grid can be optimized a bit better by detaching from the document and reattaching automatically. Maybe that could somehow be done behind the scenes when doing a resize. The out-of-the-box experience would be much better - when doing a prototype to see if a technology is stable enough to be used, these kind of issues leave a bad impression on people trying out what could be achieved. Now that I know that it has a huge impact, I will do so myself in my custom listbox... and in the next step I will upgrade the component to a GridBulkRenderer, but that will have impact on the API of the component since it supports custom rendering in the listbox. The biggest issue I have with incubator is that with every release we have to update our code: - Class names change - Package names change (gen2) - methods are renamed or refactored - Event mechanism has changed half way. We have a deadline to meet and incubator widgets are just to volatile for the moment. The Table we already started using but only after shielding off everything about the incubator because we can not afford to change the applications all of the time (in total we have at least 5 big GWT projects in development and many new ones are being defined for the future). David On Tue, Feb 3, 2009 at 5:21 PM, John LaBanca jlaba...@google.com wrote: The GridBulkRenderer in the GWT incubator allows you to generate a Grid as an HTML string, which is much faster than using DOM manipulation as the Grid currently does. You can also use it with the ScrollTable, which add a fixed header to a scrolling body. Or use the PagingScrollTable, which divides the rows into mulitple pages. You can find these widgets in the incubator project: http://code.google.com/p/google-web-toolkit-incubator/ Thanks, John LaBanca jlaba...@google.com On Tue, Feb 3, 2009 at 11:16 AM, stuckagain david.no...@gmail.comwrote: Beloved GWT devs, I just finished tracking down a big performance issue in one of our application and I really fell that I have to post something about the problem here. As we all know the Grid is very slow if you need to show a large table. But what I did not know is that it makes an extreem big difference when the Grid is attached or not. I had a Grid with 2000 rows (1 column) populated before attaching the widget. That takes about 5 seconds. That is not great, but since this is a border case it is good enough since most instances will only use less than 10 rows. But... we had some logic that reset the grid to contain refreshed data, but this time the grid is populated while it was already attached to the browser document. It now took 250 SECONDS to show the exact some data. The easy solution (before switching over to bulk rendering) is to simply remove the Grid from the document, populate it with the 2000 rows and put it back. Wouldn't it be nice that the components like the Grid would do such things automatically when doing big operations like resize on it ? David -- 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: let incubator's build.properties use environment variables
LGTM
On Thu, Jan 15, 2009 at 10:36 PM, fabb...@google.com wrote:
Reviewers: ecc,
Description:
Small tweak to set the env property first, so that user-preference
properties in build.properties can refer to environment variables, and
to remove the check on gwt.home, because it's going to be done in
common.ant.xml anyway (and that might have more find-the-GWT heuristics,
which would be blocked by an early test in build.xml).
Please review this at http://gwt-code-reviews.appspot.com/2206
Affected files:
build.xml
Index: build.xml
===
--- build.xml (revision 1415)
+++ build.xml (working copy)
@@ -23,22 +23,13 @@
property name=project.build.properties
value=${project.root}/build.properties /
+ property environment=env /
+
property file=${project.build.properties} /
!-- Also check for global-incubator.properties in the directory
above --
property file=${project.root}/../global-incubator.properties /
-
- property environment=env /
-
- !--
-Check for gwt.home.
---
-
- condition property=gwt.home value=${env.GWT_HOME}
- isset property=env.GWT_HOME /
- /condition
-
-
+
!-- import common config --
import file=${project.root}/common.ant.xml /
import file=${project.root}/testsets.ant.xml /
--
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: Question about Log.info,etc. methods
Both actually, though if we don't change the method names, changing the order of the parameters without breaking everyone currently using logging would be almost impossible. On Fri, Jan 16, 2009 at 11:21 AM, Isaac Truett itru...@gmail.com wrote: While I agree entirely regarding the undesirability of single-letter method names, I also wonder if perhaps Emily was referring, in part at least, to the order of the two parameters, message and category? Making that consistent doesn't seem unduly burdensome. On Fri, Jan 16, 2009 at 11:17 AM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: At a speculative guess, Android may be choosing short names to keep the compiled class files smaller, since they're such a memory-restricted environment (they also like filenames like R.java to contain what amounts to a dictionary of resource hash-references). I'm not sure I see Android as a server platform for GWT apps, so that issue goes away for us in the compile and obfuscate cycle of client code for the Android browser. So I second Joel's yuck, and see no reason to override the aesthetic objection. ;-) On Fri, Jan 16, 2009 at 10:38 AM, Joel Webber j...@google.com wrote: Log.i()? Yuck. On Thu, Jan 15, 2009 at 12:54 PM, Emily Crutcher e...@google.com wrote: In some ways, android is now a sister project of gwt. For our static logging, we use methods like Log.info(String message, String category) the same method in android is Log.i(String category, String message). Is it worth normalizing those static method calls? -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Question about Log.info,etc. methods
Currently, none of the variations that I tried where categories were not strings maintained the property that all logging messages were completely compiled away. If you can figure one out, I'd be very interested. cheers, Emily On Fri, Jan 16, 2009 at 11:44 AM, Isaac Truett itru...@gmail.com wrote: What about finding some way to make the parameters type safe? Perhaps a simple Category class that wraps a String? Writing Log.info(new Category(message), category) would jump out at me as being very noticeably wrong. That would avoid the confusion now between Log.info() and Log.i(). Is the extra verbosity worth it? On Fri, Jan 16, 2009 at 11:30 AM, Emily Crutcher e...@google.com wrote: Both actually, though if we don't change the method names, changing the order of the parameters without breaking everyone currently using logging would be almost impossible. On Fri, Jan 16, 2009 at 11:21 AM, Isaac Truett itru...@gmail.com wrote: While I agree entirely regarding the undesirability of single-letter method names, I also wonder if perhaps Emily was referring, in part at least, to the order of the two parameters, message and category? Making that consistent doesn't seem unduly burdensome. On Fri, Jan 16, 2009 at 11:17 AM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: At a speculative guess, Android may be choosing short names to keep the compiled class files smaller, since they're such a memory-restricted environment (they also like filenames like R.java to contain what amounts to a dictionary of resource hash-references). I'm not sure I see Android as a server platform for GWT apps, so that issue goes away for us in the compile and obfuscate cycle of client code for the Android browser. So I second Joel's yuck, and see no reason to override the aesthetic objection. ;-) On Fri, Jan 16, 2009 at 10:38 AM, Joel Webber j...@google.com wrote: Log.i()? Yuck. On Thu, Jan 15, 2009 at 12:54 PM, Emily Crutcher e...@google.com wrote: In some ways, android is now a sister project of gwt. For our static logging, we use methods like Log.info(String message, String category) the same method in android is Log.i(String category, String message). Is it worth normalizing those static method calls? -- 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't -- 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: Making listener wrapper public
How about WrappedClickListener instead then? I want a prefix rather then a suffix because we don't want these classes to show up prominently when you do a type search in an ide. On Fri, Jan 16, 2009 at 2:57 PM, jlaba...@google.com wrote: Everything looks good except the names. If we are making this public, then WrapClick sounds weird as a class name. Generally, class names are nouns, but Wrap is a verb. I suggest changing all of them to ClickListenerWrapper (or the equivalent for other listeners). Event ClickWrapper seems a little vague to me. http://gwt-code-reviews.appspot.com/2207 -- 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 tweaks to the new event infrastructure
The reasons we narrow the type is to allow the following:
1. the ability to have users deprecate their listeners cleanly
2. the ability to create an internal gwt reporting system that gives
users feedback on where/what their handlers are used
3. the ability to, in a later release, create an event propagation system
for widgets
On Thu, Jan 15, 2009 at 10:01 AM, rj...@google.com wrote:
http://gwt-code-reviews.appspot.com/2205/diff/1/24
File user/src/com/google/gwt/user/client/ui/Widget.java (left):
http://gwt-code-reviews.appspot.com/2205/diff/1/24#oldcode53
Line 53: public final HandlerManager getHandlers() {
On 2009/01/15 14:53:37, ecc wrote:
I think that would be a much larger breaking change if we did not
override the
return type here.
I think it's too soon to think that way with this code. All of its users
are early adopters who haven't even had access to it in an RC, or
internal users whom we're perfectly capable of fixing.
Narrowing the type is the odd thing to do, and if we don't have a
compelling reason to do it, we shouldn't. IMHO
http://gwt-code-reviews.appspot.com/2205
--
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 tweaks to the new event infrastructure
As most of the code review comments are moot, due to the change in how the
interface is implemented, capturing the two issues left here:
*gwt.*.foo.Foo* -- has, in general, meant getting the content of the entire
package.
My suggestion is to add another naming convention to get the essential
code:
*gwt.*.foo.FooBase* -- gets just the stuff absolutely needed for the
sub-packages to work.
So, for events
*gwt.event.Even*t -- gets all the currently defined gwt event structure.
*gwt.event.EventBase* - gets the core infrastructure needed.
The only other thing is rather then having DomEvent extend User, why don't
we have DomEvent extend com.google.gwt.user.DOM?
The reason for DefaultHandlerRegistration was because, if you look at the
javadoc, you'll see we've left ourselves the option of actually adding to
that interface. The purpose of default handler registration was to give
users a way to avoid being broken if/when that happens if they needed to
implement their own handler registration. We could replace it with a public
DelegatingHandlerRegistration though,or we could say we will definitely not
break the HandlerRegistration interface.
On Thu, Jan 15, 2009 at 3:10 PM, Emily Crutcher e...@google.com wrote:
Yep, that's a requirement, the only question, in my mind, is how to name
the modules.
On Thu, Jan 15, 2009 at 2:09 PM, Ray Cromwell cromwell...@gmail.comwrote:
Being able to pick out only base events is crucial for me, as trying to
package the DOM classes in some environments leads to breakage (e.g.
Android) -Ray
On Thu, Jan 15, 2009 at 10:45 AM, j...@google.com wrote:
http://gwt-code-reviews.appspot.com/2205/diff/1/6
File user/src/com/google/gwt/event/Event.gwt.xml (right):
http://gwt-code-reviews.appspot.com/2205/diff/1/6#newcode2
Line 2: source path=shared/
On 2009/01/15 14:53:37, ecc wrote:
In almost all other cases in gwt, the module corresponding to the
package name
included everything. What about renaming this module to
EventInfrastructure or
EventBase if that is no longer true?
The way things were before, it was impossible to take only the Event
module, without picking up both the dom and logical packages. That would
make this entire exercise pointless, because you wouldn't be able to
reuse common event infrastructure without picking up a dependency on
User.
The only solutions to this are (a) what we have here or (b) to get rid
of the event package hierarchy, which would leave us with something
like:
gwt.event.Event
gwt.domevent.DomEvent
gwt.logicalevent.LogicalEvent
I don't care a great deal, but having a structure that makes it
impossible to pick out the modules you want is unacceptable.
http://gwt-code-reviews.appspot.com/2205/diff/1/8
File user/src/com/google/gwt/event/shared/HandlerCollection.java
(right):
http://gwt-code-reviews.appspot.com/2205/diff/1/8#newcode23
Line 23: */
On 2009/01/15 14:53:37, ecc wrote:
wording seems slightly awkward, can you rephrase? Something like
Contains a
collection of handlers, exposing the ability ...
It doesn't actually *contain* a collection of handlers, but I've
reworded it a bit anyway.
http://gwt-code-reviews.appspot.com/2205/diff/1/7
File user/src/com/google/gwt/event/shared/HandlerManager.java (right):
http://gwt-code-reviews.appspot.com/2205/diff/1/7#newcode307
Line 307:
On 2009/01/15 14:53:37, ecc wrote:
would prefer to have this method on a separate util class that is then
javadoc'd
to be only used by people implementing new handler collections
(EventManagementUtil maybe?)
Done.
http://gwt-code-reviews.appspot.com/2205/diff/1/7#newcode365
Line 365: HandlerManager.this.removeHandler((TypeEventHandler) type,
handler);
On 2009/01/14 22:50:06, rjrjr wrote:
Why is this an improvement over DefaultHandlerRegistration? We have
arguably
less type safety, and no fewer classes.
Not sure I follow -- DefaultHandlerRegistration assumed and required the
use of HandlerManager, so you couldn't use them separately. All it
appeared to do was implement the semantics of an inner class with a lot
more typing (i.e., it had manually written ctor and fields that are just
copies of now-final locals (HandlerManager.this, type, handler), and
both implementations of removeHandler() contain the exact same typecast.
I can't figure out a single reason for separating it into a top-level
class.
http://gwt-code-reviews.appspot.com/2205/diff/1/24
File user/src/com/google/gwt/user/client/ui/Widget.java (left):
http://gwt-code-reviews.appspot.com/2205/diff/1/24#oldcode53
Line 53: public final HandlerManager getHandlers() {
On 2009/01/15 15:01:08, rjrjr wrote:
On 2009/01/15 14:53:37, ecc wrote:
I think that would be a much larger breaking change if we did not
override the
return type here.
I think it's too soon to think that way with this code. All of its
users are
early adopters who haven't even had access to it in an RC
[gwt-contrib] Re: PopupPanel -- RollDown animation
Thanks, committed as r4448.
On Wed, Jan 14, 2009 at 10:27 AM, John LaBanca jlaba...@google.com wrote:
LGTM
One nit:
You set bottom = (int) (progress * offsetHeight), but you could just use
bottom = top + height or even just bottom = height.
Thanks,
John LaBanca
jlaba...@google.com
On Tue, Jan 13, 2009 at 2:41 PM, e...@google.com wrote:
Reviewers: jlabanca,
Description:
For SuggestBox and DropDownListBox, porting the RollDown animation class
from incubator. Testing in the suggest box visual test.
Please review this at http://gwt-code-reviews.appspot.com/2004
Affected files:
user/src/com/google/gwt/user/client/ui/PopupPanel.java
Index: user/src/com/google/gwt/user/client/ui/PopupPanel.java
===
--- user/src/com/google/gwt/user/client/ui/PopupPanel.java (revision
4431)
+++ user/src/com/google/gwt/user/client/ui/PopupPanel.java (working
copy)
@@ -100,7 +100,7 @@
* /ul
*/
static enum AnimationType {
-CENTER, ONE_WAY_CORNER
+CENTER, ONE_WAY_CORNER, ROLL_DOWN
}
/**
@@ -144,7 +144,7 @@
// Determine if we need to animate
boolean animate = curPanel.isAnimationEnabled;
- if (curPanel.animType == AnimationType.ONE_WAY_CORNER !showing)
{
+ if (curPanel.animType != AnimationType.CENTER !showing) {
animate = false;
}
@@ -210,17 +210,25 @@
int bottom = 0;
int height = (int) (progress * offsetHeight);
int width = (int) (progress * offsetWidth);
- if (curPanel.animType == AnimationType.CENTER) {
-top = (offsetHeight - height) 1;
-left = (offsetWidth - width) 1;
- } else if (curPanel.animType == AnimationType.ONE_WAY_CORNER) {
-if (LocaleInfo.getCurrentLocale().isRTL()) {
- left = offsetWidth - width;
-}
+ switch (curPanel.animType) {
+case ROLL_DOWN:
+ right = offsetWidth;
+ bottom = (int) (progress * offsetHeight);
+ break;
+case CENTER:
+ top = (offsetHeight - height) 1;
+ left = (offsetWidth - width) 1;
+ right = left + width;
+ bottom = top + height;
+ break;
+case ONE_WAY_CORNER:
+ if (LocaleInfo.getCurrentLocale().isRTL()) {
+left = offsetWidth - width;
+ }
+ right = left + width;
+ bottom = top + height;
+ break;
}
- right = left + width;
- bottom = top + height;
-
// Set the rect clipping
impl.setClip(curPanel.getElement(), getRectString(top, right,
bottom,
left));
--
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 tweaks to the new event infrastructure
The general idea of decoupling the handler manager from the actual events
seems like a great goal, and I think we are on the right track, a couple of
problems with the current implementation...
---
Removing getHandlers() unforutnately makes firing most logical events
type-unsafe. We can decouple the handler manager by making getHandlers()
return the HandlerCollection interface however in order to avoid this
problem.
--
As a user, within my handler, I expect to be able to safely call all methods
on my event. The user, however, cannot safely call setSource and have it
work, but it will appear to work in many circumstances, therefore setting
him/her up for problems later. So having a public setSource() on event seems
like a very bad idea.
For example:
...
MyEvent myEvent = new MyEvent();
*myEvent.setSource(childWidget);*
* delegateEvent(childWidget, myEvent)*
seems like valid code but is actually incorrect and prevents us from killing
the event at the correct time.
Making the source an invariant would mean we could no longer cache all of
our dom events and would have to remove the currently supported ability to
delegate events from one widget to another.
Now, personally, I would prefer to have the access method on another class
altogether, as it is still a bit too easy to find on HandlerManager.
However, I would have absolutely no sympathy for a user who tried to
something like this and used a method off of a EventDispatchUtil class.
Assume we have a logical event that is expensive to create (maybe it needs
server information) named ExpensiveEvent.
A composite widget may/may not have to create an ExpensiveEvent on some user
state change, depending upon whether it or any of its children have an
ExpensiveHandler.
isEventHandled() allows the widget to know if it needs to create an
expensive event or not.
On Wed, Jan 14, 2009 at 4:36 PM, Ray Ryan rj...@google.com wrote:
On Wed, Jan 14, 2009 at 1:18 PM, Joel Webber j...@google.com wrote:
All,
I've run into a few snags trying to use the new event system with some
custom libraries, and would like to propose a few changes that would make it
easier to reuse the GwtEvent hierarchy without necessarily using all of the
infrastructure in com.google.gwt.event.*
When trying to fire GwtEvents without using HandlerManager (don't ask...
but it is a legitimate use-case), I hit a couple of brick walls. The first
was that GwtEvent.setSource() was package-protected, so that only
HandlerManager was intended to be able to call it. This makes it impossible
to usefully create one on your own.
To solve this first problem, I simply added a static setEventSource()
method to HandlerManager. Even though it's in HandlerManager, I can use it
without pulling in the rest of it, and still not tempt event users to try
setting the event's source.
public static void setEventSource(GwtEvent? event, Object source) {
event.setSource(source);
}
I don't buy that this is an improvement over just making the method public.
How do you figure that users will be less tempted to call this than to use
the instance method?
If it's that big a concern, let's make source an invariant, and make it a
constructor argument on GwtEvent.
The second issue was that HasHandlers had the method getHandlers() that
returns a HandlerManager. This effectively tightly couples HandlerManager to
the use of GwtEvent. It also exposes all event sources' HandlerManagers as
part of their public API, which doesn't seem useful and constrains their
ability to evolve implementations in the future.
My proposal for this problem is as follows:
Create a HandlerCollection interface that HandlerManager implements. This
makes the use of HandlerManager an implementation detail rather than an API
decision.
public interface HandlerCollection {
boolean isEventHandled(Type? type);
void fireEvent(GwtEvent? event);
}
I then removed getHandlers() from HasHandlers (this interface is now
empty, and could probably be removed as well).
Can you go ahead and remove it?
This method was being used by methods such as ResizeEvent.fire(). I
propose simply requiring fire() to take the HandlerCollection as an argument
(DomEvent.fire() already works this way, so it doesn't seem like much of a
stretch). This keeps the fire() methods from having to call
source.getHandlers(), and allows us to remove HasHandlers.getHandlers()
altogether.
public static void fire(HandlerCollection handlers, HasResizeHandlers
source,
int width, int height) { ... }
I've attached a patch that implements this change. It touches a lot of
files, but the changes are all pretty simple. I also refactored the Event
modules slightly, so that it's possible to include only the shared event
infrastructure, and just the logical and/or dom events (I also fixed the
fact
[gwt-contrib] Re: Proposed tweaks to the new event infrastructure
this and used a method off of a EventDispatchUtil class.
But we don't actually recycle events anywhere, do we? This is one of the
open issues left from the review process as the event stuff was merged in to
the 1.6 branch last year--why do we have this complicated mechanism that we
don't actually use?
We recycle all dom events, so we are already in this use case.
It is not that we are pretending it is not public, the method is public, but
for a different set of users: Normal Widget/Event creators should never,
ever, use this method. However, with the decoupling of HandlerManager from
the rest of the event system we have introduced a new class of users
handler management system implementors They, and only they, should need
access to it.
On Wed, Jan 14, 2009 at 4:36 PM, Ray Ryan rj...@google.com wrote:
On Wed, Jan 14, 2009 at 1:18 PM, Joel Webber j...@google.com wrote:
All,
I've run into a few snags trying to use the new event system with some
custom libraries, and would like to propose a few changes that would make
it
easier to reuse the GwtEvent hierarchy without necessarily using all of the
infrastructure in com.google.gwt.event.*
When trying to fire GwtEvents without using HandlerManager (don't ask...
but it is a legitimate use-case), I hit a couple of brick walls. The first
was that GwtEvent.setSource() was package-protected, so that only
HandlerManager was intended to be able to call it. This makes it impossible
to usefully create one on your own.
To solve this first problem, I simply added a static setEventSource()
method to HandlerManager. Even though it's in HandlerManager, I can use it
without pulling in the rest of it, and still not tempt event users to try
setting the event's source.
public static void setEventSource(GwtEvent? event, Object source)
{
event.setSource(source);
}
I don't buy that this is an improvement over just making the method
public. How do you figure that users will be less tempted to call this than
to use the instance method?
If it's that big a concern, let's make source an invariant, and make it a
constructor argument on GwtEvent.
The second issue was that HasHandlers had the method getHandlers() that
returns a HandlerManager. This effectively tightly couples HandlerManager
to
the use of GwtEvent. It also exposes all event sources' HandlerManagers as
part of their public API, which doesn't seem useful and constrains their
ability to evolve implementations in the future.
My proposal for this problem is as follows:
Create a HandlerCollection interface that HandlerManager
implements. This makes the use of HandlerManager an implementation detail
rather than an API decision.
public interface HandlerCollection {
boolean isEventHandled(Type? type);
void fireEvent(GwtEvent? event);
}
I then removed getHandlers() from HasHandlers (this interface is now
empty, and could probably be removed as well).
Can you go ahead and remove it?
This method was being used by methods such as ResizeEvent.fire(). I
propose simply requiring fire() to take the HandlerCollection as an
argument
(DomEvent.fire() already works this way, so it doesn't seem like much of a
stretch). This keeps the fire() methods from having to call
source.getHandlers(), and allows us to remove HasHandlers.getHandlers()
altogether.
public static void fire(HandlerCollection handlers, HasResizeHandlers
source,
int width, int height) { ... }
I've attached a patch that implements this change. It touches a lot of
files, but the changes are all pretty simple. I also refactored the Event
modules slightly, so that it's possible to include only the shared event
infrastructure, and just the logical and/or dom events (I also fixed the
fact that the dom event module didn't have an explicit inherits of
User.gwt.xml (for the Event class -- mostly a technicality since it will
always be included practically speaking).
If you upload the patch to Rietveld, I'll be happy to take the review.
One other quick question: Does Widget.isEventHandled() actually get used
anywhere? I can't find any references to it. I can see it perhaps being
useful for widget implementors, but so far no one does, and it's public,
which seems a bit odd.
Please remove it.
The patch is not 100% tested yet, but I wanted to get feedback before
taking it any further. This may seem like a pedantic exercise, but I think
it's important to start taking steps to carefully decouple modules sooner
rather than later.
Cheers,
joel.
--
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't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Why do DateBox.Format.parse() and format() need DateBox?
Daniel, You have some good points and what you are describing is almost exactly the date box we initially had in gwt-incubator. We ran into a few significant problems that made us change to the current design: 1. DateTimeFormat represents a very sophisticated API, it was difficult for users to replace the formatting/parsing of dates because, to do so they needed to understand the internals of the date time format class. 2. The most desirable default parsing behavior was a hybrid between a DateTimeFormat + a fall back to the browser's own parsing algorithms, this could not be cleanly modeled using just the DateTimeFormat. 3. When we used a template method to allow users to override the error reporting for date box, we still got a lot of people not finding it, as the typical users looked for a setter of some flavor. On Tue, Jan 13, 2009 at 11:49 AM, dflorey daniel.flo...@gmail.com wrote: Seems to be a matter of taste ;-) If parse() and format() should be capable of sophisticated error handling (like triggering a popup to show the error or whatever) I'd prefer to simply implement them as protected methods in DateBox + passing DateTimeFormat to cstr instead of Format interface and let user customize the behaviour by subclassing DateBox. I just wanted to report that it looked strange to me at first sight and as I'm totally average this also could confuse others... On Jan 13, 5:36 pm, Ray Ryan rj...@google.com wrote: DateFormat isn't just a parser, nor even mainly a parser. It lets you customize the display of your datebox in response to bad input. And because we pass DateBox in as a parameter, your DateFormat can be a shared flyweight. rjrjr On Tue, Jan 13, 2009 at 8:08 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'm for the first time using the new 1.6 DateBox.Format feature and I wonder why I have to pass a DateBox to the format() and parse() methods. The DateBox is used in the parse method to display parsing errors. I would prefer to let parse() throw an IllegalArgumentException when parsing fails and catch this exception in the enclosing parseDate() method. This would clean up the DateBox.Format interface. If you agree I can provide a tiny patch... Cheers, Daniel -- 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: Why do DateBox.Format.parse() and format() need DateBox?
1. DateTimeFormat represents a very sophisticated API, it was difficult for users to replace the formatting/parsing of dates because, to do so they needed to understand the internals of the date time format class. Try extending DateTimeFormat rather then using the predefined constants to see this problem. 2. The most desirable default parsing behavior was a hybrid between a DateTimeFormat + a fall back to the browser's own parsing algorithms, this could not be cleanly modeled using just the DateTimeFormat. Where can I find this browser's own parsing algorithms in the current code? The default date formatter includes this code. 3. When we used a template method to allow users to override the error reporting for date box, we still got a lot of people not finding it, as the typical users looked for a setter of some flavor. I guess for 99% of usecases the default behaviour of applying an error style to the date box is sufficient. The 1% of usecases that want to do more sophisticated error handling should be able to override the parse() method and catch the exception. If I want to do my own error handling right now I have to: Implement my own Formatter or subclass DefaultFormat anyway and implement/override the parse method and I don't see why this is any better than just subclassing DateBox. People tend to look for set* methods first, so it easier for them to find the correct methods to override, the actually mechanism is the same. On Tue, Jan 13, 2009 at 11:49 AM, dflorey daniel.flo...@gmail.com wrote: Seems to be a matter of taste ;-) If parse() and format() should be capable of sophisticated error handling (like triggering a popup to show the error or whatever) I'd prefer to simply implement them as protected methods in DateBox + passing DateTimeFormat to cstr instead of Format interface and let user customize the behaviour by subclassing DateBox. I just wanted to report that it looked strange to me at first sight and as I'm totally average this also could confuse others... On Jan 13, 5:36 pm, Ray Ryan rj...@google.com wrote: DateFormat isn't just a parser, nor even mainly a parser. It lets you customize the display of your datebox in response to bad input. And because we pass DateBox in as a parameter, your DateFormat can be a shared flyweight. rjrjr On Tue, Jan 13, 2009 at 8:08 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'm for the first time using the new 1.6 DateBox.Format feature and I wonder why I have to pass a DateBox to the format() and parse() methods. The DateBox is used in the parse method to display parsing errors. I would prefer to let parse() throw an IllegalArgumentException when parsing fails and catch this exception in the enclosing parseDate() method. This would clean up the DateBox.Format interface. If you agree I can provide a tiny patch... Cheers, Daniel -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why do DateBox.Format.parse() and format() need DateBox?
There is an effort planned for next quarter to create the global date binding/error handling/etc. solution. The problem is that is that we wanted to introduce a usable date box this release, not next, so we created the interface that would be least likely to clash with a global solution. On Tue, Jan 13, 2009 at 1:16 PM, dflorey daniel.flo...@gmail.com wrote: One last point before I shut up: If there would be another widget supporting the Format interface it would make sense to have a dedicated interface. But then again it would make no sense to pass a DateBox as this ties the Formatter to this particular widget. If there would be a abstract Format interface with parse() and format () the DateTimeFormat would be a perfect candidate for implementing this. This would enable users to come up with simple implementations if you this DateTimeFormat is too complex. If we do not decouple DateBox and DateBox.Format it is just adding unnecessary complexity IMO. On Jan 13, 7:10 pm, dflorey daniel.flo...@gmail.com wrote: I know this is nitpicking, but some comments inline On Jan 13, 6:53 pm, Emily Crutcher e...@google.com wrote: Daniel, You have some good points and what you are describing is almost exactly the date box we initially had in gwt-incubator. We ran into a few significant problems that made us change to the current design: 1. DateTimeFormat represents a very sophisticated API, it was difficult for users to replace the formatting/parsing of dates because, to do so they needed to understand the internals of the date time format class. I don't see the difference. If we would get rid of the Format interface we would end up with 3 cstrs: DateBox() = same as now DateBox(Date date) = same as above, but with initial date set DateBox(DatePicker dp, Date date, DateTimeFormat format) = for advanced users that want to specify the format It's even simpler than it is now where I have to write new DateBox(new DatePicker(), new Date(), new DefaultFormat (DateTimeFormat.getShortDateFormat()) to change the format instead of new DateBox(new DatePicker(), new Date(), DateTimeFormat.getShortDateFormat()) 2. The most desirable default parsing behavior was a hybrid between a DateTimeFormat + a fall back to the browser's own parsing algorithms, this could not be cleanly modeled using just the DateTimeFormat. Where can I find this browser's own parsing algorithms in the current code? 3. When we used a template method to allow users to override the error reporting for date box, we still got a lot of people not finding it, as the typical users looked for a setter of some flavor. I guess for 99% of usecases the default behaviour of applying an error style to the date box is sufficient. The 1% of usecases that want to do more sophisticated error handling should be able to override the parse() method and catch the exception. If I want to do my own error handling right now I have to: Implement my own Formatter or subclass DefaultFormat anyway and implement/override the parse method and I don't see why this is any better than just subclassing DateBox. On Tue, Jan 13, 2009 at 11:49 AM, dflorey daniel.flo...@gmail.com wrote: Seems to be a matter of taste ;-) If parse() and format() should be capable of sophisticated error handling (like triggering a popup to show the error or whatever) I'd prefer to simply implement them as protected methods in DateBox + passing DateTimeFormat to cstr instead of Format interface and let user customize the behaviour by subclassing DateBox. I just wanted to report that it looked strange to me at first sight and as I'm totally average this also could confuse others... On Jan 13, 5:36 pm, Ray Ryan rj...@google.com wrote: DateFormat isn't just a parser, nor even mainly a parser. It lets you customize the display of your datebox in response to bad input. And because we pass DateBox in as a parameter, your DateFormat can be a shared flyweight. rjrjr On Tue, Jan 13, 2009 at 8:08 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'm for the first time using the new 1.6 DateBox.Format feature and I wonder why I have to pass a DateBox to the format() and parse() methods. The DateBox is used in the parse method to display parsing errors. I would prefer to let parse() throw an IllegalArgumentException when parsing fails and catch this exception in the enclosing parseDate() method. This would clean up the DateBox.Format interface. If you agree I can provide a tiny patch... Cheers, Daniel -- 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
[gwt-contrib] Re: setKeyCode doesn't work in firefox
LGTM
On Fri, Jan 9, 2009 at 11:53 AM, jlaba...@google.com wrote:
Reviewers: ecc,
Description:
The keyCode is a read only attribute in all browsers except IE. This
patch deprecates the setKeyCode method so we can remove it in a future
release.
Here is the associated issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=25
Please review this at http://gwt-code-reviews.appspot.com/2002
Affected files:
user/src/com/google/gwt/user/client/DOM.java
user/src/com/google/gwt/user/client/ui/TextBoxBase.java
Index: user/src/com/google/gwt/user/client/DOM.java
===
--- user/src/com/google/gwt/user/client/DOM.java(revision 4419)
+++ user/src/com/google/gwt/user/client/DOM.java(working copy)
@@ -626,7 +626,10 @@
*
* @param evt the event whose key code is to be set
* @param key the new key code
+ * @deprecated this method only works in IE and should not have been
added to
+ * the API
*/
+ @Deprecated
public static void eventSetKeyCode(Event evt, char key) {
impl.eventSetKeyCode(evt, key);
}
Index: user/src/com/google/gwt/user/client/ui/TextBoxBase.java
===
--- user/src/com/google/gwt/user/client/ui/TextBoxBase.java (revision
4419)
+++ user/src/com/google/gwt/user/client/ui/TextBoxBase.java (working
copy)
@@ -226,7 +226,10 @@
* listeners to easily filter keyboard input.
*
* @param key the new key value
+ * @deprecated this method only works in IE and should not have been
added to
+ * the API
*/
+ @Deprecated
public void setKey(char key) {
if (currentEvent != null) {
DOM.eventSetKeyCode(currentEvent, key);
--
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: 1.6 date picker question
By the way, now that gwt-incubator is sourced against 1.6, if you can retarget your DropDownDatePicker for 1.6 and the com.google.gwt.gen2.picker package I'd love to review it. On Fri, Dec 5, 2008 at 1:08 AM, Emily Crutcher e...@google.com wrote: Also, the code should be reviewed before committing. I'll be happy to be your reviewer once we land the 1.6 datepicker + release the 1.5 final gwt-incubator drop. As until then, we cannot add 1.6 specific code to gwt-incubator. On Fri, Dec 5, 2008 at 1:05 AM, Emily Crutcher e...@google.com wrote: Yep, sounds right, thanks! On Thu, Dec 4, 2008 at 6:53 PM, Isaac Truett itru...@gmail.com wrote: On second thought, gwt-incubator is supposed to compile against trunk, isn't it? Well, since this is written to compile against the 1_6_datepicker branch, I'll hold off committing until that branch is merged to trunk (soon, right...?). I've attached the DropDownDatePicker proof-of-concept patch. It's very, very ugly, but it works. I'll see about tending to the style a little bit when I have more time. Comments welcome, of course. - Isaac On Thu, Dec 4, 2008 at 10:36 AM, Emily Crutcher e...@google.com wrote: That sounds great, thanks. On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett itru...@gmail.com wrote: I wrote a MonthSelector a while back that uses DropDownListBoxes for month and year. I can fix it up to be compatible with recent changes and add it to the incubator. I'll see if I can fit that in tonight. On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher e...@google.com wrote: It is definitely something that we would consider. Of course, the first step would be to get some good alternative month selectors into the gwt-incubator... On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson arthur.k...@gmail.com wrote: 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 jlaba...@google.com 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 jlaba...@google.com On Mon, Dec 1, 2008 at 9:41 AM, Arthur Kalmenson arthur.k...@gmail.com 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 -- 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't -- 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't -- 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: Prosposed API Change - Deprecate TextBoxBase#setKey() and DOM#eventSetKeyCode()
+1 from me. On Thu, Jan 8, 2009 at 4:52 PM, John LaBanca jlaba...@google.com wrote: Contributors - Description: = I proposed that we deprecate DOM#eventSetKeyCode() and TextBoxBase#setKey() because they only work in IE and the same functionality would be difficult to simulate on other browsers. These methods allow you to change the keyCode on keyboard events, which actually changes the character that will be typed into TextBoxes. However, the attribute is readonly in all browsers except IE, which means that you will see a JS error on FireFox, Safari, and Opera. Simulating this reliably would be incredibly difficult because it involves canceling the native event and creating a new one, so I propose that we deprecate it for now without any replacement. If we come up with some alternative in the future, we can add it. You can see the full issue here: http://code.google.com/p/google-web-toolkit/issues/detail?id=25 Thanks, John LaBanca jlaba...@google.com -- 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: @SingleImpl versus @SingleJsoImpl
In the library code we constantly use *Impl to denote a class that users should not look at, but here we we have *Impl annotations that is part of a public API. Could we modify the name slightly so we can keep the *Impl convention consistant throughout the gwt code base? On Wed, Jan 7, 2009 at 11:17 AM, John Tamplin j...@google.com wrote: On Wed, Jan 7, 2009 at 10:48 AM, Bruce Johnson br...@google.com wrote: Does anyone buy that reasoning? An important related question is whether these things are actually compiler flags or whether they are module settings. I think they are actually more appropriate as the latter. If they are module flags, what happens when you have different settings for different modules (as you point out, it will be impossible to keep them consistent in a large code base with shared code)? If it is a compile-time error, then some code simply won't be shareable between projects -- maybe that is ok if that module's owner has decided it is important enough to set the flag in a library module? If it is based on which module it is in, does the caller or callee win the battle, and will that behavior be surprising to a developer? Regarding the original question, I don't have a strong preference for either solution over the other. #2 does have additional utility, but it seems less consistent than simply saying that after type tightening there must be exactly one implementation. Given the primary use case is shared code between client and server which will use a JSO object in the client (at least until generators are able to produce a JSO subclass), I am not sure the additional utility is worth the hidden code size risk and slightly inconsistency. -- John A. Tamplin Software Engineer (GWT), Google -- 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: @SingleImpl versus @SingleJsoImpl
FormPanelImplHost is an example of an impl interface. I think once users see one *Impl type that has documented useful functionality for them, they are less likely to ignore the next *Impl class/interface/annotation they see that looks like it might be useful for them, regardless of whether the *Impl type is an annotation, interface, or class. On Wed, Jan 7, 2009 at 12:26 PM, Bruce Johnson br...@google.com wrote: @Emily: Does the fact that it's an annotation not make it completely clear? We don't use *Impl on interfaces anywhere (do we?) On Wed, Jan 7, 2009 at 11:46 AM, Emily Crutcher e...@google.com wrote: In the library code we constantly use *Impl to denote a class that users should not look at, but here we we have *Impl annotations that is part of a public API. Could we modify the name slightly so we can keep the *Impl convention consistant throughout the gwt code base? On Wed, Jan 7, 2009 at 11:17 AM, John Tamplin j...@google.com wrote: On Wed, Jan 7, 2009 at 10:48 AM, Bruce Johnson br...@google.com wrote: Does anyone buy that reasoning? An important related question is whether these things are actually compiler flags or whether they are module settings. I think they are actually more appropriate as the latter. If they are module flags, what happens when you have different settings for different modules (as you point out, it will be impossible to keep them consistent in a large code base with shared code)? If it is a compile-time error, then some code simply won't be shareable between projects -- maybe that is ok if that module's owner has decided it is important enough to set the flag in a library module? If it is based on which module it is in, does the caller or callee win the battle, and will that behavior be surprising to a developer? Regarding the original question, I don't have a strong preference for either solution over the other. #2 does have additional utility, but it seems less consistent than simply saying that after type tightening there must be exactly one implementation. Given the primary use case is shared code between client and server which will use a JSO object in the client (at least until generators are able to produce a JSO subclass), I am not sure the additional utility is worth the hidden code size risk and slightly inconsistency. -- John A. Tamplin Software Engineer (GWT), Google -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Review of handler map speed test.
It was a proprietary one actually, so its name was deliberately omitted, however as it is a very large application, so should be pretty indicative of most well designed applications. +1 from me for Joel's conclusion. On Tue, Jan 6, 2009 at 4:17 PM, Ray Ryan rj...@google.com wrote: What was the large application? On Tue, Jan 6, 2009 at 1:13 PM, Joel Webber j...@google.com wrote: I ran a quick test to determine how many handlers get added in actual applications. For Showcase, after opening all the samples, it looks something like this:- addHandler() is called 128 times - Widgets with: - 1 handler: 103 - 2 handlers: 6 - 3 handlers: 1 - 5 handlers: 2 I also ran these tests on the largest internal application I know of, and came up with the following numbers (for the initial load, which involves lots of widgets): - addHandler(): called 266 times - 1 handler: 36 - 2 handlers: 23 - 3 handlers: 24 - 4 handlers: 1 - 5 handlers: 7 - 6 handlers: 8 - 7 handlers: 2 - 11 handlers: 1 Note that in the latter case, I believe much of the code is still using methods like addMouseListener() and addKeyListener(), which overzealously add handlers (i.e., mousemove/up/down/over/out and keyup/down/press). As this is narrowed, I expect the numbers to be even lower. This is approximately two orders of magnitude less than the 30k number in the tests below, so even for the largest applications, we're very unlikely to run into problems. Thus, I believe that the simplicity and code savings of having a simplified HandlerManager (i.e. one that just uses JRE classes or simple native maps) would be worth it. IMHO, anyway. On Mon, Dec 1, 2008 at 11:36 AM, Emily Crutcher e...@google.com wrote: Joel, Thank you so much for looking into this! Below is the review request that was originally directed to Kelly. Also, I've cut/pasted the initial benchmark results I got from it. The way I interpret them is that we may/may not have a significant problem depending upon how many handlers programs actually have. As you can imagine, the fact that the string manipulation is globally slowed down if we don't use the flattened data structure is what most concerns me, as if this is a realistic number of handlers for a production system and this benchmark holds true, we would be slowing down this sort of string operation by over 90%. == Start handlerMapForSimpleJs Test== Creating 5000 handlerMapForSimpleJs maps 78 millseconds, 78 millseconds, 78 millseconds Adding 6 handlers for 5000 to a handlerMapForSimpleJs 312 millseconds, 266 millseconds, 329 millseconds Fired 3 handlers for 5000 widgets using handlerMapForSimpleJs 157 millseconds, 156 millseconds, 156 millseconds created a random string with 3 handlers using handlerMapForSimpleJs 156 millseconds, 203 millseconds, 219 millseconds == Start handlerMapForJs Test== Creating 5000 handlerMapForJs maps 78 millseconds, 94 millseconds, 109 millseconds Adding 6 handlers for 5000 to a handlerMapForJs 188 millseconds, 171 millseconds, 187 millseconds Fired 3 handlers for 5000 widgets using handlerMapForJs 157 millseconds, 157 millseconds, 172 millseconds created a random string with 3 handlers using handlerMapForJs 109 millseconds, 94 millseconds, 94 millseconds == Start handlerMapForJava Test== Creating 5000 handlerMapForJava maps 172 millseconds, 172 millseconds, 172 millseconds Adding 6 handlers for 5000 to a handlerMapForJava 453 millseconds, 453 millseconds, 469 millseconds Fired 36 handlers for 5000 widgets using handlerMapForJava 312 millseconds, 312 millseconds, 312 millseconds created a random string with 3 handlers using handlerMapForJava 141 millseconds, 188 millseconds, 188 millseconds -- Forwarded message -- From: Emily Crutcher e...@google.com Date: Mon, Nov 17, 2008 at 2:50 PM Subject: Review of handler map speed test. To: Kelly Norton knor...@google.com, Ray Ryan rj...@google.com, Google Web Toolkit Contributors Google-Web-Toolkit-Contributors@googlegroups.com Kelly, Could you review this visual benchmark I was using to compute the pros/cons of the different handler maps? Of particular interest is the SimpleJsHandlerMap, to see if there is anything, well, simple we we can do to make it faster. http://code.google.com/p/google-web-toolkit/source/detail?r=4089 -- 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't -- 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: review request: add missing packages to javadoc
Can we automatically include all shared and client (excluding impl) packages instead of manually listing them out? It seems like that may be less of a maintenance headache at least for the user package organization. On Mon, Jan 5, 2009 at 11:34 AM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: Two semantically-equivalent patches attached: I think we want the following new packages in the user javadoc set, but they weren't there. - com.google.gwt.event.dom.client - com.google.gwt.event.logical.shared - com.google.gwt.event.shared - com.google.gwt.debug.client - com.google.gwt.datepicker.client I waffled around OOPHM, but decided I shouldn't add it yet. The vertical patch is worse for diff'ing today, but breaks the package lists to be one-per-line for easier to manipulation later. That's the one I want to submit, the other is there for easier diff this time. Relative to trunk r4375. -- 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: Code review request, Creating gen2 versions of Time and Date Spinner to use the new 1.6 datepicker and event system
On Mon, Jan 5, 2009 at 5:16 AM, dflorey daniel.flo...@gmail.com wrote: btw: Why is the datepicker in a separate package and why is this package not located under user/client/ui? It looks very strange to me that the datepicker package is currently on the same level as server, theme and tools... For new large user modules, we wanted to give users the option of not including that code by default, therefore these types of modules are being put into com.google.gwt.user.*name-of-module* rather then under com.google.gwt.user.client.*name-of-module*. On 4 Jan., 18:37, dflorey daniel.flo...@gmail.com wrote: Hi Emily, Happy new year to all of you! I've been suffering from a real-world virus but hope to fully recover soon... I just upgraded my branch to the latest revision and tried to have a look at your port. The actual TimePicker looks good to me, but when testing the new 1.6 DateBox I struggled to add a ValueChangeHandler. The onValueChange method is never called. As far as I can see all the events fired by the DatePicker and the TextBox are consumed by the DateBoxHandler, but they will not fire a valueChangeEvent on the DateBox as the setValue method will be called with fireEvent=false. Once this is fixed I'd like to implement a TimeBox similar to DateBox but using a more usefull TimePicker (seehttp:// code.google.com/p/google-web-toolkit-incubator/issues/detail?i... ) Cheers, Daniel On 30 Dez. 2008, 18:33, Emily Crutcher e...@google.com wrote: Dear Daniel, I hope you are having a great holiday. I've added a gen2 version of TimePicker and DatePickerPicker in a new com.google.gwt.gen2.picker package. It now depends upon the gwt 1.6 date picker and event system. If you could review my changes and make any more you deem appropriate, that would be great! Thanks, Emily Change link: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r... 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Code review request, Creating gen2 versions of Time and Date Spinner to use the new 1.6 datepicker and event system
Dear Daniel, I hope you are having a great holiday. I've added a gen2 version of TimePicker and DatePickerPicker in a new com.google.gwt.gen2.picker package. It now depends upon the gwt 1.6 date picker and event system. If you could review my changes and make any more you deem appropriate, that would be great! Thanks, Emily Change link: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1379 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: RR: SuggestBox uprades
This is not a promise, but here is what is on my list for the first round of SuggestBox upgrades, which I hope to do as soon as we've finished everything critical for 1.6 (hence why it is not a promise). The others probably need more design vetting, so are somewhat unlikely to make it in. 1. Remove final from SuggestBox. 2. Add showSuggestions()/hideSuggestions()/isShowingSuggestion methods. 3. Add showDefaultSuggestions() 4. Wire up SuggestBox to use Popup Panel's showRelative method. 5. Make escape key close the suggestion popup. 6. (Stretch goal) rework MultiWordSuggestOracle to be more extensible. On Mon, Dec 22, 2008 at 10:30 AM, Isaac Truett itru...@gmail.com wrote: Thanks, John. Would some SuggestBox updates, sans DropDownPanel, be possible? Here's my holiday SuggestBox API wishlist: 1. showSuggestions() and showSuggestions(String query) - basically the same as this patch. 2. hideSuggestions() - the same as this patch. 3. selectItem(int index) - select an item from suggestion menu. 4. getSuggestionMenuSelectedItemIndex() - the index of the selected suggestion menu item. 5. isShowingSuggestions() - Is the suggestion menu open? 6. doSelectedItemAction() - public delegate method to suggestionMenu.doSelectedItemAction(). I can provide a patch for these if the concepts meet with approval. - Isaac On Mon, Dec 22, 2008 at 10:20 AM, John LaBanca jlaba...@google.com wrote: [+ecc] to make sure this shows up in her inbox I think we cut this out of the plans for GWT 1.6 because the DropDownPanel wasn't ready for prime time. I'm not sure about the status of the RPCRequestOracle, so that might still be on the table. Thanks, John LaBanca jlaba...@google.com On Sat, Dec 20, 2008 at 10:36 PM, Isaac Truett itru...@gmail.com wrote: Whatever happened to this change? I noticed issue #2739 requesting hideSuggestions() and this patch would seem to satisfy that request. Is there any chance of this patch or something similar making 1.6? On Tue, Apr 29, 2008 at 4:25 PM, Emily Crutcher e...@google.com wrote: Below are the SuggestBox API modifications under consideration. Feedback is very welcome. Thanks, Emily Make SuggestBox depend upon a DropDownPanel to control its popup, allowing users to customize the behavior, including where it is located and what item is selected by default. Add a requestDefaultSuggestions method to the SuggestOracle, use it in SuggestBox. Add hideSuggestions()/showSuggestions() method Add a new RPCSuggestOracle which, if extended from, guarantees that only one request can be extent at once. Add HighlightHandler support to SuggestBox P.S The attached patch is against the gwt-incubator, as gwt itself is under feature lock down. The only changes to SuggestOracle and MultiWordSuggestOracle is the inclusion of the method requestDefaultSuggestions(). 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Extra space on tree when Treeitem selected is a composite widget only on firefox
LGTM. On Mon, Dec 22, 2008 at 3:17 PM, jlaba...@google.com wrote: Here is the bug: http://code.google.com/p/google-web-toolkit/issues/detail?id=504 http://gwt-code-reviews.appspot.com/1803 -- 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: Add NativePreviewEvent to replace current EventPreview system (version 4)
This seems like the right model of behavior. I wonder if we could figure out a way to tweak the API exposing the behavior though when you get back from vacation? As a user, I think I might get confused by the interactions of setAlwaysAutoHide(), setAutoHidePartner, setAutoHide(true/false),isAutoHideEnabled(), and isAlwaysAutoHide(), so I'm hoping there is a way to represent the same information with fewer moving parts. Cheers, Emily On Mon, Dec 22, 2008 at 12:46 PM, jlaba...@google.com wrote: Reviewers: ecc, Description: The latest version of this patch introduces PopupPanel.setAlwaysAutoHide(). Unlike autoHide, alwaysAutoHide indicates that the PopupPanel should autoHide even if it isn't at the top of the stack. The only time it does not autoHide is if a modal popup is open above it. We have also gone back to NativePreviewEvent.cancel()/consume(). Both the SuggestBox and MenuBar setAlwaysAutoHide to true. However, the MenuBar overrides the event preview to handle all of its unique special cases. Please review this at http://gwt-code-reviews.appspot.com/1801 Affected files: reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue1932.java reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForDialogBox.java user/src/com/google/gwt/event/dom/client/DomEvent.java user/src/com/google/gwt/event/dom/client/HasNativeEvent.java user/src/com/google/gwt/event/shared/GwtEvent.java user/src/com/google/gwt/event/shared/HandlerManager.java user/src/com/google/gwt/user/client/DOM.java user/src/com/google/gwt/user/client/Event.java user/src/com/google/gwt/user/client/EventPreview.java user/src/com/google/gwt/user/client/ui/DialogBox.java user/src/com/google/gwt/user/client/ui/MenuBar.java user/src/com/google/gwt/user/client/ui/PopupPanel.java user/src/com/google/gwt/user/client/ui/SuggestBox.java user/test/com/google/gwt/user/UISuite.java user/test/com/google/gwt/user/client/EventTest.java user/test/com/google/gwt/user/client/ui/PopupTest.java -- 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: Add dateBoxFormatError to dark and chrome style themes
LGTM
On Mon, Dec 22, 2008 at 11:41 AM, jlaba...@google.com wrote:
Reviewers: ecc,
Description:
The dateBoxFormatError style name is applied to a DateBox with an
invalid date entry. This patch adds style definitions to the dark and
chrome style themes. Style definitions were already added for the
standard theme.
Patch was submitted TBR by ecc.
Please review this at http://gwt-code-reviews.appspot.com/1601
Affected files:
user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
Index:
user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
===
---
user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
(revision 4363)
+++
user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
(working copy)
@@ -1093,10 +1093,9 @@
.gwt-DateBox input {
width: 8em;
}
-.dateBoxFormatError{
- background:#ff;
+.dateBoxFormatError {
+ background: #ff;
}
-
.dateBoxPopup {
}
Index: user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
===
--- user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
(revision 4363)
+++ user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
(working copy)
@@ -999,6 +999,10 @@
.gwt-DateBox input {
width: 8em;
}
+.dateBoxFormatError {
+ background: #a8eeff;
+ color: red;
+}
.dateBoxPopup {
}
Index: user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
===
--- user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
(revision 4363)
+++ user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
(working copy)
@@ -1000,6 +1000,10 @@
.gwt-DateBox input {
width: 8em;
}
+.dateBoxFormatError {
+ background: #a8eeff;
+ color: red;
+}
.dateBoxPopup {
}
Index:
user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
===
--- user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
(revision 4363)
+++ user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
(working copy)
@@ -1094,6 +1094,9 @@
.gwt-DateBox input {
width: 8em;
}
+.dateBoxFormatError {
+ background: #eed6d6;
+}
.dateBoxPopup {
}
Index:
user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
===
---
user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
(revision 4363)
+++
user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
(working copy)
@@ -1095,6 +1095,9 @@
.gwt-DateBox input {
width: 8em;
}
+.dateBoxFormatError {
+ background: #eed6d6;
+}
.dateBoxPopup {
}
--
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: Themes/Alpha Transpary/IE7 the Holly Hack!
Good point, added as issue 3234.
On Fri, Dec 19, 2008 at 3:40 AM, Andy Moorley andy.moor...@gmail.comwrote:
Hi there
Been struggling a bit with some of the effects of the GWT style sheets
in an attempt to get round IE6 alpha transparancy.
In the top of standard.css (com.google.gwt.user.theme.standard) there
is the lines
* In order to maintain cross-browser compatibility, the following
syntax is
* used to create IE6 specific style rules:
*htmlbody .gwt-Widget {
* Rule applies to all browsers (including IE7), except IE6
*}
** html .gwt-Widget {
* Rule applied to IE6 only (not to IE7)
*}
*
And in various places it then uses this Holly hack to apply the MS
AlphaTransparency DX fix..
* html .gwt-MenuBarPopup .menuPopupBottomCenter {
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='gwt/
standard/images/ie6/hborder_gray_shadow.png',sizingMethod='scale');
}
The trouble is that IE7 ONLY ignore the Holly hack when in standards
mode - but as we know, at present the recommend (and to be honest only
real way) of using GWT is in quirks mode - so the IE6 only fix is
being picked up by IE7.
I therefore think if quicks mode is to be preferred approach for
next few releases, this CSS should probably use a different way to
identify IE6 only.
Thanks
Andy
--
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: gwt-incubator has created a 1.5 branch
I think you might be thinking about GWT rather then gwt-incubator. gwt-incubator releases only has two sub folders in it: 1. http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/releases/1.5, which has the gwt-incubator code that is compatable with gwt 1.5. 2. http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/releases/1.4, which has the gwt-incubator code that is compatable with gwt 1.4. gwt-incubator trunk will have the gwt 1.6 support, so there are currently no plans for a releases/1.6. Let me know if any of that doesn't make sense! Cheers, Emily On Mon, Dec 29, 2008 at 6:41 PM, Ray Cromwell cromwell...@gmail.com wrote: Is the /releases/1.6 going to be the branch that becomes 1.6? There are two other 1.6 branches in /branches as well. -Ray On Mon, Dec 29, 2008 at 1:28 PM, Emily Crutcher e...@google.com wrote: We have just released another gwt-incubator drop for gwt 1.5.3, which we hope will be the final gwt-incubator drop compatible with gwt 1.5. As part of that process, there is now a gwt-incubator 1.5 branch. Any future (hopefully non existent) gwt-incubator 1.5 drops will be based on that branch. This means that gwt-incubator's trunk now is now certified to be compatible with the current gwt trunk and gwt 1.6 builds. When we have a milestone gwt 1.6 build, we will drop anchor there. In the meantime, anyone who wants to work against the gwt-incubator trunk will also need to setup a gwt 1.6 build from the gwt source. Also, if you are relying on a relatively new gwt 1.6 feature, you will have to check that the feature has made it into gwt trunk as well, otherwise gwt-incubator's continuous build will break and we will come after you with padded clubs. Just so you know, the current punishment for breaking the build is to pledge two hours of support work to make the build more resiliant :-). Feel free to respond to this thread with any questions/comments. For the majority of you who are currently on vacation, happy holidays! Cheers, Emily -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: gwt-incubator has created a 1.5 branch
And yep, for the gwt code base, the releases/1.6 will become the 1.6 release. Cheers, Emily On Mon, Dec 29, 2008 at 9:15 PM, Emily Crutcher e...@google.com wrote: I think you might be thinking about GWT rather then gwt-incubator. gwt-incubator releases only has two sub folders in it: 1. http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/releases/1.5, which has the gwt-incubator code that is compatable with gwt 1.5. 2. http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/releases/1.4, which has the gwt-incubator code that is compatable with gwt 1.4. gwt-incubator trunk will have the gwt 1.6 support, so there are currently no plans for a releases/1.6. Let me know if any of that doesn't make sense! Cheers, Emily On Mon, Dec 29, 2008 at 6:41 PM, Ray Cromwell cromwell...@gmail.comwrote: Is the /releases/1.6 going to be the branch that becomes 1.6? There are two other 1.6 branches in /branches as well. -Ray On Mon, Dec 29, 2008 at 1:28 PM, Emily Crutcher e...@google.com wrote: We have just released another gwt-incubator drop for gwt 1.5.3, which we hope will be the final gwt-incubator drop compatible with gwt 1.5. As part of that process, there is now a gwt-incubator 1.5 branch. Any future (hopefully non existent) gwt-incubator 1.5 drops will be based on that branch. This means that gwt-incubator's trunk now is now certified to be compatible with the current gwt trunk and gwt 1.6 builds. When we have a milestone gwt 1.6 build, we will drop anchor there. In the meantime, anyone who wants to work against the gwt-incubator trunk will also need to setup a gwt 1.6 build from the gwt source. Also, if you are relying on a relatively new gwt 1.6 feature, you will have to check that the feature has made it into gwt trunk as well, otherwise gwt-incubator's continuous build will break and we will come after you with padded clubs. Just so you know, the current punishment for breaking the build is to pledge two hours of support work to make the build more resiliant :-). Feel free to respond to this thread with any questions/comments. For the majority of you who are currently on vacation, happy holidays! Cheers, Emily -- 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't -- 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: Introducing DateBox.Format
John, as I just got a vacation message from Ray, could you finish the review of this patch? The only unreviewed part is adding the abandon method as per Ray's request. Thanks! Emily http://gwt-code-reviews.appspot.com/1201 On Fri, Dec 19, 2008 at 1:20 AM, Emily Crutcher e...@google.com wrote: I think I would find it pretty odd if a formatter did not put the date box back into a neutral state after the date box is empty, but I'm happy to put the abandon method in, as it doesn't seem that harmful either. On Fri, Dec 19, 2008 at 1:10 AM, Ray Ryan rj...@google.com wrote: You're assuming, I think, that the Format will only be used to do interesting things in response to an error. There is nothing in its name or its contract to imply that should be the case. If I came in cold, I'd expect I could use it to decorate the date box whether or not it was in an error state, especially with a neutral name like Format. rjrjr On Fri, Dec 19, 2008 at 5:07 PM, Emily Crutcher e...@google.com wrote: On Thu, Dec 18, 2008 at 6:42 PM, rj...@google.com wrote: Seems like we're missing a method from the Format interface? http://gwt-code-reviews.appspot.com/1201/diff/12/14 File user/src/com/google/gwt/user/datepicker/client/DateBox.java (right): http://gwt-code-reviews.appspot.com/1201/diff/12/14#newcode173 Line 173: Date parse(DateBox dateBox, String text, boolean reportError); You don't think we need an abandon() or cleanup() method? How will my formatter take away a style that your formatter doesn't know about? Shouldn't the formatter always restore the date box to a pristine state when it is asked to format an empty string? http://gwt-code-reviews.appspot.com/1201 -- 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't -- 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: Optimized build-demos task
22 or so, as long as you can rely just on the compile task, it's actually not a problem. However, to be safe, we need to call build first, as we use the gwt-incubator jar now to generate the demos. Calling gwt-incubator build then does take some time. In my measurements, not having to call build each time shaved about 40 seconds off of the compile time. On Fri, Dec 19, 2008 at 11:12 AM, Isaac Truett itru...@gmail.com wrote: LGTM. How many demos are you compiling? I tested the patch on a batch of 11 demos and I didn't see a difference in time. On Fri, Dec 19, 2008 at 10:37 AM, Emily Crutcher e...@google.com wrote: Isaac, Could you review this patch? It re-jiggers the ant tasks to make build-demos a bit more efficient, because after I moved the other demos in, the task was taking a while. At some point, we might think about making the build/build test tasks themselves have guards to build only once, however that should probably be done as a group (including the testing tests), so I opted for the easier solution here while trying to prep the public jar. Cheers, Emily -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Tree alignment issues
LGTM, though I think you mean to add I18n to the single issue module. Also, did you check how the samples looked now that you removed the spacing? Thanks, Emily On Fri, Dec 19, 2008 at 1:18 PM, John LaBanca jlaba...@google.com wrote: ping Please review this when you get a chance. Thanks, John LaBanca jlaba...@google.com On Tue, Dec 16, 2008 at 2:02 PM, jlaba...@google.com wrote: Associated issues: http://code.google.com/p/google-web-toolkit/issues/detail?id=2854 http://code.google.com/p/google-web-toolkit/issues/detail?id=2859 http://gwt-code-reviews.appspot.com/611 -- 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: Issue 210 - demo index
Yep, LGTM. On Thu, Dec 18, 2008 at 10:07 AM, Isaac Truett itru...@gmail.com wrote: Thank you! I'm glad you like it. Ideally I would want to keep the old output around and check for staleness before recompiling. However, I don't have a practical method for determining staleness of the demos (yet). I don't see any problem with deleting compiled-demos for now. Looks good with the addition of the initial delete? On Wed, Dec 17, 2008 at 9:03 PM, Emily Crutcher e...@google.com wrote: That is absolutely awesome! Here are the gen2 widgets using your patch posted on app engine. http://collectionofdemos.appspot.com/demo/index.html When the build.demos target is invoked, is there any reason we should not clear the entire directory first? That would save us from including old demos if/when we get the automatic posting task completed. (Right now running into the 1000 file/unit limit on app-engine, boo ho). On Wed, Dec 17, 2008 at 5:06 PM, Isaac Truett itru...@gmail.com wrote: Emily, The attached patch adds an index.html page to the build-demos output. This page contains links to all of the compiled demos. Demos are loaded into an iframe on the page for easy testing across demos. - Isaac -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Introducing DateBox.Format
On Thu, Dec 18, 2008 at 6:42 PM, rj...@google.com wrote: Seems like we're missing a method from the Format interface? http://gwt-code-reviews.appspot.com/1201/diff/12/14 File user/src/com/google/gwt/user/datepicker/client/DateBox.java (right): http://gwt-code-reviews.appspot.com/1201/diff/12/14#newcode173 Line 173: Date parse(DateBox dateBox, String text, boolean reportError); You don't think we need an abandon() or cleanup() method? How will my formatter take away a style that your formatter doesn't know about? Shouldn't the formatter always restore the date box to a pristine state when it is asked to format an empty string? http://gwt-code-reviews.appspot.com/1201 -- 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: Any objections to 1.5-final gwt-incubator drop going out this week?
Being able to compile all the demos automatically is already a big win over the old procedure, so thank you for the work you've already done! Did you see this enhancement request I put in yesterday by any chance? ( http://code.google.com/p/google-web-toolkit-incubator/issues/detail?id=210), that would also be a very big help, because it would avoid a whole bunch of manually editing and clicking on urls. On Wed, Dec 17, 2008 at 11:01 AM, Isaac Truett itru...@gmail.com wrote: +1. Let me know if I can assist with the transition. On Wed, Dec 17, 2008 at 10:25 AM, Emily Crutcher e...@google.com wrote: For gwt-incubator users who are using svn tip from gwt-1.6 or gwt-trunk, we currently are in a confusing situation of having two different, almost identical event systems: one in gwt-incubator itself and one in gwt. In many cases, both are currently in use. Additionally, we have tons of deprecation warnings, because gwt-incubator widgets cannot switch to the real event handlers so are stuck using listeners. To fix this situation, we need to post a gwt-incubator 1.5 final relatively soon. Until the next gwt-incubator jar drop, the gwt-incubator tip would then only be certified to work with gwt-trunk svn tip. After the first gwt 1.6 milestone or release candidate, gwt-incubator would be certified to work against that 1.6 jar and gwt-trunk. Objections anyone? -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Any objections to 1.5-final gwt-incubator drop going out this week?
For gwt-incubator users who are using svn tip from gwt-1.6 or gwt-trunk, we currently are in a confusing situation of having two different, almost identical event systems: one in gwt-incubator itself and one in gwt. In many cases, both are currently in use. Additionally, we have tons of deprecation warnings, because gwt-incubator widgets cannot switch to the real event handlers so are stuck using listeners. To fix this situation, we need to post a gwt-incubator 1.5 final relatively soon. Until the next gwt-incubator jar drop, the gwt-incubator tip would then only be certified to work with gwt-trunk svn tip. After the first gwt 1.6 milestone or release candidate, gwt-incubator would be certified to work against that 1.6 jar and gwt-trunk. Objections anyone? -- 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] RR: Introducing DateBox.Format interface
We have introduced a new interface into DateBox called Format and providing a DefaultFormat class. You can see the code herehttp://gwt-code-reviews.appspot.com/1201. this interface has the following advantages: - As the date parsing is now completely replaceable, our default parser can be more permissive then when we were using a raw DateTimeFormat object. Specifically, now, by default, we can fall back to letting the browser try to parse the date if the original DateTimeFormat parse failed, this should lead to less end-user frustration. - We avoid the need for the BadDateReporter interface, as the user can use their Format instance to control what the user sees when parsing fails, this way whenever the validation effort kicking off next year comes up with an official solution, we won't have to deprecate any current date box code. - For users that are trying to avoid the overhead of including the code for DateTimeFormat.parse, there is now a way to do so. 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: Introducing DateBox.Format
cal state. You can add an abandon() method to the format lifecycle, to tell it to clean up its crap. To make sure my formatter doesn't interfere with someone else's styling, change the CSS class name for errors to reflect that the formatter owns it, not the DateBox, e.g. DATE_BOX_DEFAULT_FORMAT_ERROR Am I correct that this is your solution? - Each formatter has its own style name, the expectation is that the css for the widget should be dependent upon that stylename and no other process should use that style name. - Whenever the date box's content is parsed or formatted, the date box would first call abandon/reset on the formatter. During the abandon/reset method, the formatter would access the date box's class dom property and do a string comparison to see if it had to remove the error condition before proceding. Formatters that did not use the css style name directly to indicate format errors would have to figure out some other way of clearing any current format state. I think that would work, but it seems somewhat less efficient then the current solution, can you explain a bit more why it is more desirable? On 2008/12/17 22:41:41, rjrjr wrote: The dateBox field seems wrong, you don't need the circular relationship btw. DateBox and format. Instead, why don't you pass in the dateBox as a param to format, parse and reset--and allow yourself to share instances? Then you can get rid of this init method entirely. http://gwt-code-reviews.appspot.com/1201 -- 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: Introducing DateBox.Format
Yep, one way you get to store local information about your format state, the other way you get to share a single format object. As I get the feeling you care more about sharing a single format class then I care about allowing the format to have state, so I'll fhmp. Cheers, Emily On Wed, Dec 17, 2008 at 7:21 PM, Ray Ryan rj...@google.com wrote: Who cares? This is happening in response to a user action, and will be undetectable. Why would we flush the ability to have shared formats to avoid parsing the CSS? We're just talking about a call to UIObject#removeStyleDependentName here, right? rjrjr On Thu, Dec 18, 2008 at 11:15 AM, Emily Crutcher e...@google.com wrote: When a default format instance receives a format or parse request, how does it know whether it needs to remove its error style name from that date box other then getting the current css off the date box and parsing it? On Wed, Dec 17, 2008 at 7:09 PM, Ray Ryan rj...@google.com wrote: Nope. Each formatter *class* can attach dependent styles to a datebox. It should do so using a naming convention s.t. it can tell styles it has added from styles that others have added. (This was your concern that lead to the back pointer, right?) When a formatter is removed from a datebox (by a new one being added), it receives an abandon call to give it a chance clean up any css (or whatever) that it may have applied that another format will not know how to delete. No less efficient, and no need to instantiate a formatter per date box. rjrjr On Thu, Dec 18, 2008 at 11:04 AM, Emily Crutcher e...@google.com wrote: cal state. You can add an abandon() method to the format lifecycle, to tell it to clean up its crap. To make sure my formatter doesn't interfere with someone else's styling, change the CSS class name for errors to reflect that the formatter owns it, not the DateBox, e.g. DATE_BOX_DEFAULT_FORMAT_ERROR Am I correct that this is your solution? - Each formatter has its own style name, the expectation is that the css for the widget should be dependent upon that stylename and no other process should use that style name. - Whenever the date box's content is parsed or formatted, the date box would first call abandon/reset on the formatter. During the abandon/reset method, the formatter would access the date box's class dom property and do a string comparison to see if it had to remove the error condition before proceding. Formatters that did not use the css style name directly to indicate format errors would have to figure out some other way of clearing any current format state. I think that would work, but it seems somewhat less efficient then the current solution, can you explain a bit more why it is more desirable? On 2008/12/17 22:41:41, rjrjr wrote: The dateBox field seems wrong, you don't need the circular relationship btw. DateBox and format. Instead, why don't you pass in the dateBox as a param to format, parse and reset--and allow yourself to share instances? Then you can get rid of this init method entirely. http://gwt-code-reviews.appspot.com/1201 -- 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't -- 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: Issue 210 - demo index
That is absolutely awesome! Here are the gen2 widgets using your patch posted on app engine. http://collectionofdemos.appspot.com/demo/index.html When the build.demos target is invoked, is there any reason we should not clear the entire directory first? That would save us from including old demos if/when we get the automatic posting task completed. (Right now running into the 1000 file/unit limit on app-engine, boo ho). On Wed, Dec 17, 2008 at 5:06 PM, Isaac Truett itru...@gmail.com wrote: Emily, The attached patch adds an index.html page to the build-demos output. This page contains links to all of the compiled demos. Demos are loaded into an iframe on the page for easy testing across demos. - Isaac -- 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: A couple more small tweaks to the gwt-incubator build target
Can you add an issue for that? As it seems like we should probably sweep
through both jars and check for extraneous output.
Committed at r1323.
Cheers,
Emily
On Tue, Dec 16, 2008 at 10:26 AM, Isaac Truett itru...@gmail.com wrote:
LGTM.
One other change that we might want to make is to filter out the -aux
dirs from compiled-demo when building the zip. They're harmless but
extraneous.
On Tue, Dec 16, 2008 at 10:01 AM, Emily Crutcher e...@google.com wrote:
Isaac,
Could you review these small extra changes to the gwt-incubator
build
file?
Moving demo output to be a sibling of the generated javadocs. Both
should
eventually be automatically posted on gwt-incubator's app engine demo
site.
Adding a dependency on build.demos to dist, as we want the sanity check
that
building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett itru...@gmail.com
wrote:
Good enough for me. Here's the patch for building demos off of the
jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory=${gwtc.vm.maxMemory}
classpath
path path=${gwtc.src.dir} /
-path path=${project.src} /
-path path=${project.bin} /
+path path=${project.jar} /
pathelement location=${gwt.user.jar} /
pathelement location=${gwt.dev.jar} /
pathelement location=${gwt.tools}/lib/w3c/sac/sac-1.3.jar
/
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher e...@google.com
wrote:
The reasons I would prefer to use the gwt-incubator.jar is because
that
gives us a quick sanity check that the gwt-incubator jar is
actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a variable, which it probably
should)
If project.src or project.bin was overridden, those changes should
be
reflected in the gwt-incubator jar, if they are not, that is
definitely
a
problem we would want to catch sooner rather then later.
+ build-demos doesn't depend on building a jar first
The gwt-incubator jar currently takes 12 seconds to compile on my
relatively
slow laptop, so depending upon the gwt-incubator build running
first
does
not seem like it introduces an undue burden on the developer.
cheers,
Emily
--
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't
--
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] Update to slider bar.
Daniel, Could you review this change? Focus Panel no longer sinks Focus, Key, or Mouse events by default. Therefore, adding a sink events call to SliderBar itself. Code: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1322 Thanks, Emily -- 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] A couple more small tweaks to the gwt-incubator build target
Isaac,
Could you review these small extra changes to the gwt-incubator build
file?
1. Moving demo output to be a sibling of the generated javadocs. Both
should eventually be automatically posted on gwt-incubator's app engine demo
site.
2. Adding a dependency on build.demos to dist, as we want the sanity
check that building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett itru...@gmail.com wrote:
Good enough for me. Here's the patch for building demos off of the jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory=${gwtc.vm.maxMemory}
classpath
path path=${gwtc.src.dir} /
-path path=${project.src} /
-path path=${project.bin} /
+path path=${project.jar} /
pathelement location=${gwt.user.jar} /
pathelement location=${gwt.dev.jar} /
pathelement location=${gwt.tools}/lib/w3c/sac/sac-1.3.jar /
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher e...@google.com wrote:
The reasons I would prefer to use the gwt-incubator.jar is because
that
gives us a quick sanity check that the gwt-incubator jar is actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a variable, which it probably should)
If project.src or project.bin was overridden, those changes should be
reflected in the gwt-incubator jar, if they are not, that is
definitely
a
problem we would want to catch sooner rather then later.
+ build-demos doesn't depend on building a jar first
The gwt-incubator jar currently takes 12 seconds to compile on my
relatively
slow laptop, so depending upon the gwt-incubator build running first
does
not seem like it introduces an undue burden on the developer.
cheers,
Emily
--
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't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
demobuild.patch
Description: Binary data
[gwt-contrib] Re: Tree alignment issues
Should we, in general, be adding padding to RadioButtons and CheckBoxes, as won't other users have the same problems? On Tue, Dec 16, 2008 at 11:40 AM, jlaba...@google.com wrote: Reviewers: ecc, Description: Description: This patch addresses a bunch of Tree alignment issues: 1. RadioButtons and CheckBoxes do not align with other tree nodes because the GWT style sheet adds padding to them, AND because the browser adds a margin to these elements. 2. In RTL mode, leaf items do not have correct padding because we always set the padding on the left. 3. In RTL mode in IE, the focus element does not line up with the TreeItem because IE does not position the span correctly. Fixes: == 1. We now remove the padding of RadioButtons and Checkboxes when they are in a TreeItem. Also, we remove the browser margins added to the native input elements. In IE, the spacing around the native input is not a margin, so we use a negative margin to offset it. 2. We now check for RTL mode when adding the padding to the TreeItem. 3. I added zoom:1 to TreeItems in the RTL GWT theme style sheets, which corrects the problem in IE but doesn't affect other browsers. Testing: I updated VisualsForTree to include a TreeItem with a RadioButton and a TreeItem with a CheckBox, and verified alignment in all browsers, for all themes, in RTL and LTR mode. I also manually verified that the Showcase is unaffected by the change. I modified SingleIssue.gwt.xml to inherit all style theme resources, and I added the ar locale to make it easier to test RTL mode in general. Please review this at http://gwt-code-reviews.appspot.com/609 Affected files: reference/code-museum/src/com/google/gwt/museum/SingleIssue.gwt.xml reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForTree.java user/src/com/google/gwt/user/client/ui/Tree.java user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css -- 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: Review request: add super source dir to incubator demo build
The reasons I would prefer to use the gwt-incubator.jar is because that gives us a quick sanity check that the gwt-incubator jar is actually including everything needed to run the demos! + project.src and project.bin can be overridden, if desired (super could be overridden if it used a variable, which it probably should) If project.src or project.bin was overridden, those changes should be reflected in the gwt-incubator jar, if they are not, that is definitely a problem we would want to catch sooner rather then later. + build-demos doesn't depend on building a jar first The gwt-incubator jar currently takes 12 seconds to compile on my relatively slow laptop, so depending upon the gwt-incubator build running first does not seem like it introduces an undue burden on the developer. cheers, Emily --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review, adding gwt-externals to gwt incubator
Thanks! On Fri, Dec 12, 2008 at 1:08 AM, Ray Ryan rj...@google.com wrote: This broke incubator for non-committers, as it was tied to https://google-web-toolkit.googlecode.com/svn/trunk/build-tools (https, not http). Should be fixed by r1306. Mmmm, copy/paste errors,rjrjr On Fri, Dec 12, 2008 at 10:24 AM, Emily Crutcher e...@google.com wrote: Amit, could you review this change? Adding gwt-externals directory to gwt-incubator trunk in order to support the use of gwt's build-tools directory. Change at: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1302 Thanks, Emily -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Mouse enter/leave events need to suppressed if the user did not actually enter or leave the widg
Thanks! Updated comment to reflect new handler names rather then the old
listener ones.
Committed at r4305.
On Thu, Dec 11, 2008 at 10:22 AM, John LaBanca [EMAIL PROTECTED] wrote:
I'm getting server errors, so here is your review:
// Only fire the mouseEnter event if it's coming from outside this
mouseEnter should be mouseOver since we are firing a MouseOverEvent
// Only fire the mouseLeave event if it's actually leaving this
mouseLeave should be mouseOut since we are firing a MouseOutEvent
Otherwise, LGTM
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Thu, Dec 11, 2008 at 9:49 AM, [EMAIL PROTECTED] wrote:
Reviewers: jlabanca,
Description:
GWT issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3189q=owner:ecc%20started
Please review this at http://gwt-code-reviews.appspot.com/810
Affected files:
user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
user/src/com/google/gwt/user/client/ui/Widget.java
Index: user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
===
--- user/src/com/google/gwt/user/client/ui/ListenerWrapper.java (revision
4300)
+++ user/src/com/google/gwt/user/client/ui/ListenerWrapper.java (working
copy)
@@ -287,23 +287,11 @@
}
public void onMouseOut(MouseOutEvent event) {
- // Only fire the mouseLeave event if it's actually leaving this
- // widget.
- Element to = event.getToElement();
- Widget source = source(event);
- if (to == null || !source.getElement().isOrHasChild(to)) {
-listener.onMouseLeave(source(event));
- }
+ listener.onMouseLeave(source(event));
}
public void onMouseOver(MouseOverEvent event) {
- // Only fire the mouseEnter event if it's coming from outside this
- // widget.
- Element from = event.getFromElement();
- Widget source = source(event);
- if (from == null || !source.getElement().isOrHasChild(from)) {
-listener.onMouseEnter(source(event));
- }
+ listener.onMouseEnter(source(event));
}
public void onMouseUp(MouseUpEvent event) {
Index: user/src/com/google/gwt/user/client/ui/Widget.java
===
--- user/src/com/google/gwt/user/client/ui/Widget.java (revision 4298)
+++ user/src/com/google/gwt/user/client/ui/Widget.java (working copy)
@@ -15,6 +15,7 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.dom.client.Element;
import com.google.gwt.event.dom.client.DomEvent;
import com.google.gwt.event.logical.shared.HasHandlers;
import com.google.gwt.event.shared.EventHandler;
@@ -88,8 +89,25 @@
return handlerManager != null handlerManager.isEventHandled(type);
}
- public void onBrowserEvent(Event nativeEvent) {
-DomEvent.fireNativeEvent(nativeEvent, handlerManager);
+ public void onBrowserEvent(Event event) {
+switch (DOM.eventGetType(event)) {
+ case Event.ONMOUSEOVER:
+// Only fire the mouseEnter event if it's coming from outside
this
+// widget.
+Element from = event.getFromElement();
+if (from != null getElement().isOrHasChild(from)) {
+ return;
+}
+break;
+ case Event.ONMOUSEOUT:
+// Only fire the mouseLeave event if it's actually leaving this
+// widget.
+Element to = event.getToElement();
+if (to != null getElement().isOrHasChild(to)) {
+ return;
+}
+}
+DomEvent.fireNativeEvent(event, handlerManager);
}
/**
--
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: Add NativePreviewEvent to replace current EventPreview system
Cool, looking forward to seeing the new patch! Per our conversation, onPreviewNativeEvent will be exposed, but will only contain minimal code by default. The bulk of the code will be in a new method previewNativeEvent() Why expose onPreviewNativeEvent at all? -- 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] Code review, adding gwt-externals to gwt incubator
Amit, could you review this change? Adding gwt-externals directory to gwt-incubator trunk in order to support the use of gwt's build-tools directory. Change at: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1302 Thanks, Emily -- 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: getAbsoluteLeft/Top() returns incorrect value in IE when zoomed in
On Tue, Dec 9, 2008 at 12:42 AM, John LaBanca [EMAIL PROTECTED] wrote: Internet Explorer now works the same as Firefox. That is, with real zoom, absolute positions do not change even though the widget appears further from the left or top. I was going to put that info in the review request, but I didn't want to confuse anyone. Also, can you check what happens when you use your patched getAbsoluteLeft + getAbsoluteTop to calculate the distance between two widgets? For example Do we really need to test this? I verified that getAbsoluteLeft() returns the correct value now and is consistent between FF and IE, and I verified it against the MenuBar and SuggestBox. The fact that SuggestBoxPopup opens directly below the TextBox and MenuBarPopup opens directly below the MenuBar implicitly verified that getAbsoluteTop() + getOffsetHeight() already works. offsetHeight/Width didn't seem to be affected by this issue at all. The consistency is probably the most important thing, so if they are consistent, that is probably good enough. My worry was that setHeight/setWidth would be using different units thet getAbsoluteTop/left in the zoomed in state, and that therefore, calculations that worked normally in GWT 1.5 would start failing with GWT 1.6. However, if firefox natively already uses the zoomed in coordinate system, then those programs would already be failing, therefore it cannot be a problem. In otherwords, LGTM then. Cheers, Emily Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Dec 8, 2008 at 6:29 PM, [EMAIL PROTECTED] wrote: Have you checked to see what values getAbsoluteLeft/Top give in your demo with Firefox3 and Opera? It seems like we want all the real zooming browsers to handle this the same way. Also, can you check what happens when you use your patched getAbsoluteLeft + getAbsoluteTop to calculate the distance between two widgets? For example Widget a (absolutely positioned at (100,100) 50 px tall. Widget b flows naturally after widget a. There are no styles on any widget to confuse this poor example. Widget c's height is calculated to be getAbsoluteTop(a) - getAbsoluteTop(b) is Widget c's height the same as widget a's? http://gwt-code-reviews.appspot.com/807 -- 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: Tweaks to API checker
Committed as 4274. On Mon, Dec 8, 2008 at 8:25 PM, Amit Manjhi [EMAIL PROTECTED] wrote: LGTM On Mon, Dec 8, 2008 at 6:40 PM, [EMAIL PROTECTED] wrote: Reviewers: amitmanjhi, Description: Amit, This patch changes the gwt build.xml file to use value rather then location when defining the apicheck.oldroot ant property + adds the removal the old setImageBase method. Please review this at http://gwt-code-reviews.appspot.com/602 Affected files: build.xml tools/api-checker/config/gwt15_16userApi.conf Index: build.xml === --- build.xml (revision 4269) +++ build.xml (working copy) @@ -9,7 +9,7 @@ property name=gwt.apicheck.config location=tools/api-checker/config/gwt15_16userApi.conf/ property name=gwt.apicheck.oldroot -location=../gwt-1.5/ +value=../gwt-1.5/ target name=dist depends=dev, user, servlet, tools, jni, doc, samples description=Run the distributions gwt.ant dir=distro-source / Index: tools/api-checker/config/gwt15_16userApi.conf === --- tools/api-checker/config/gwt15_16userApi.conf (revision 4269) +++ tools/api-checker/config/gwt15_16userApi.conf (working copy) @@ -30,3 +30,4 @@ java.lang.StringBuilder::append(Ljava/lang/StringBuffer;) OVERRIDABLE_METHOD_ARGUMENT_TYPE_CHANGE com.google.gwt.user.client.ui.Button::Button(Ljava/lang/String;Lcom/google/gwt/user/client/ui/ClickListener;) OVERLOADED_METHOD_CALL com.google.gwt.user.client.ui.ToggleButton::ToggleButton(Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/ClickListener;) OVERLOADED_METHOD_CALL +com.google.gwt.user.client.ui.Tree::setImageBase(Ljava/lang/String;) MISSING \ No newline at end of file -- 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: Warning message in IE6 when using NamedFrame on SSL-secured web-site
Why is this a problem for NamedFrames but not Frames? Other then that, LGTM. On Tue, Dec 9, 2008 at 3:10 PM, [EMAIL PROTECTED] wrote: Reviewers: ecc, Description: Description: The iframe created in a NamedFrame does not have a src, so it throws a mixed content warning in IE6 on an SSL-secured website. Fix: Setting the source to javascript:'' fixes the problem, and we've used the same trick on all other iframes (history iframe, GWT module iframe). In addition, NamedFrame currently replaces the iframe created by its parent class Frame in the super constructor. This patch changes that behavior by passing the named iframe into the super constructor. The code to create the named frame has been abstracted to a private static method. Testing: = Manually verified the patch against an SSL-enabled web server. I added a simple code museum test, but it needs to be run against a secure server. Please review this at http://gwt-code-reviews.appspot.com/808 Affected files: reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue2318.java user/src/com/google/gwt/user/client/ui/NamedFrame.java -- 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] RR: Adding api-checker to selected packages in gwt-incubator
In gwt-incubator, we want to be able to tag widgets/libaries alpha/beta/releaseCandidate. However, this implies an extra level of support for releaseCandidate libraries/widgets. Specifically, between each incubator drop, if we had to break the API, which we will occasionally need to do, we want to make sure it is listed in our release notes. In order to enforce this, Amit and I are proposing that we add an api checker config to gwt-incubator for release quality libraries and widgets. For now, the process would be informal, where a config file would specify the release quality libraries and widgets. Once a library or widget was listed as a release candidate, any breaking API changes since the last gwt-incubator drop would have to be whitelisted. The whitelist config would be checked into svn so developers could submit changes + new whitelist entries on demand. Above each whitelist entry, the developer should put a comment for why the change was made and what new API should be used instead. Everytime we created a new gwt-incubator drop, we would use the comments in the whitelist to generate a breaking changes section to our release notes. The whitelist would then be reset for the next drop. The gwt project has been using the api checker very effectively for the last several months. To read more about the API checker in general, click herehttp://code.google.com/p/google-web-toolkit/wiki/GwtJavaApiCompatibilityChecker. Comments and (polite) flames welcome. Cheers, Amit and Emily -- 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: TabBar setTabText doesn't set word wrap false
Ah, I see, the normal add(String) already sets word-wrap to false. In that case LGTM. On Tue, Dec 9, 2008 at 6:05 PM, [EMAIL PROTECTED] wrote: insertTab(String text, boolean asHTML, int beforeIndex) already disabled wordWrap, and we want insertTab() and setTabText() to be consistent. setTabText() actually unwraps the text because it replaces the element. I think its too late to change the fact that we set wordWrap to false in insertTab, and I think they should be consistent. At least now users can change the value. http://gwt-code-reviews.appspot.com/604/diff/1/2 File user/src/com/google/gwt/user/client/ui/TabBar.java (right): http://gwt-code-reviews.appspot.com/604/diff/1/2#newcode488 Line 488: focusablePanel.setWidget(new HTML(html, false)); On 2008/12/09 22:57:55, ecc wrote: Why are we disabling word wrap here? Because its disabled by default in: insertTab(String text, boolean asHTML, int beforeIndex); We want them to be consistent. http://gwt-code-reviews.appspot.com/604 -- 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: 1.6 date picker question
It is definitely something that we would consider. Of course, the first step would be to get some good alternative month selectors into the gwt-incubator... On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson [EMAIL PROTECTED]wrote: 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 -- 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: Date picker branch code review requested: style methods renamed, varargs fixed
setTransientEnabledOnVisibleDates seems a bit awkward. What if we removed the VisibleDates from the name instead? So we'd have: setTransientEnabled addTransientStyleToDates etc. Why do we want people to be able to remove date styles that do not exist without getting an assertion error? Do you have a use case in mind? Cheers, Emily On Wed, Dec 3, 2008 at 8:56 PM, Ray Ryan [EMAIL PROTECTED] wrote: 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 -- 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: Date picker branch code review requested: style methods renamed, varargs fixed
Also, you might want to turn your javadoc warnings on in your IDE, as I notice that there are a lot of missing javadoc tags. On Thu, Dec 4, 2008 at 10:01 AM, Emily Crutcher [EMAIL PROTECTED] wrote: setTransientEnabledOnVisibleDates seems a bit awkward. What if we removed the VisibleDates from the name instead? So we'd have: setTransientEnabled addTransientStyleToDates etc. Why do we want people to be able to remove date styles that do not exist without getting an assertion error? Do you have a use case in mind? Cheers, Emily On Wed, Dec 3, 2008 at 8:56 PM, Ray Ryan [EMAIL PROTECTED] wrote: 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 -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: 1.6 date picker question
That sounds great, thanks. On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett [EMAIL PROTECTED] wrote: I wrote a MonthSelector a while back that uses DropDownListBoxes for month and year. I can fix it up to be compatible with recent changes and add it to the incubator. I'll see if I can fit that in tonight. On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher [EMAIL PROTECTED] wrote: It is definitely something that we would consider. Of course, the first step would be to get some good alternative month selectors into the gwt-incubator... On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson [EMAIL PROTECTED] wrote: 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 -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWTCanvas's strange behavior : timer driven animation frozen when move the mouse. (in IE, also happen when directly write vml markups)
Could you create a in issue for this problem here: http://code.google.com/p/google-web-toolkit-incubator/issues/entry Thanks! Emily On Wed, Dec 3, 2008 at 8:56 AM, Revv [EMAIL PROTECTED] wrote: 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. -- 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] Looking for a owner of ProgressBar
Does anyone volunteer to support the ProgressBar widget in gwt-incubator? Thanks! Emily -- 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: 1.6 date picker question
Yep, sounds right, thanks! On Thu, Dec 4, 2008 at 6:53 PM, Isaac Truett [EMAIL PROTECTED] wrote: On second thought, gwt-incubator is supposed to compile against trunk, isn't it? Well, since this is written to compile against the 1_6_datepicker branch, I'll hold off committing until that branch is merged to trunk (soon, right...?). I've attached the DropDownDatePicker proof-of-concept patch. It's very, very ugly, but it works. I'll see about tending to the style a little bit when I have more time. Comments welcome, of course. - Isaac On Thu, Dec 4, 2008 at 10:36 AM, Emily Crutcher [EMAIL PROTECTED] wrote: That sounds great, thanks. On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett [EMAIL PROTECTED] wrote: I wrote a MonthSelector a while back that uses DropDownListBoxes for month and year. I can fix it up to be compatible with recent changes and add it to the incubator. I'll see if I can fit that in tonight. On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher [EMAIL PROTECTED] wrote: It is definitely something that we would consider. Of course, the first step would be to get some good alternative month selectors into the gwt-incubator... On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson [EMAIL PROTECTED] wrote: 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 -- 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't -- 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: 1.6 date picker question
Also, the code should be reviewed before committing. I'll be happy to be your reviewer once we land the 1.6 datepicker + release the 1.5 final gwt-incubator drop. As until then, we cannot add 1.6 specific code to gwt-incubator. On Fri, Dec 5, 2008 at 1:05 AM, Emily Crutcher [EMAIL PROTECTED] wrote: Yep, sounds right, thanks! On Thu, Dec 4, 2008 at 6:53 PM, Isaac Truett [EMAIL PROTECTED] wrote: On second thought, gwt-incubator is supposed to compile against trunk, isn't it? Well, since this is written to compile against the 1_6_datepicker branch, I'll hold off committing until that branch is merged to trunk (soon, right...?). I've attached the DropDownDatePicker proof-of-concept patch. It's very, very ugly, but it works. I'll see about tending to the style a little bit when I have more time. Comments welcome, of course. - Isaac On Thu, Dec 4, 2008 at 10:36 AM, Emily Crutcher [EMAIL PROTECTED] wrote: That sounds great, thanks. On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett [EMAIL PROTECTED] wrote: I wrote a MonthSelector a while back that uses DropDownListBoxes for month and year. I can fix it up to be compatible with recent changes and add it to the incubator. I'll see if I can fit that in tonight. On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher [EMAIL PROTECTED] wrote: It is definitely something that we would consider. Of course, the first step would be to get some good alternative month selectors into the gwt-incubator... On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson [EMAIL PROTECTED] wrote: 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 -- 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't -- 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't --~--~-~--~~~---~--~~ 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: 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
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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
This seems like the right philosophy to me, and your point about date pickers having an optional range is a very persuasive one, so I'm sold on the best guess with the widget being able to throw IllegalArgumentException as well. On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca [EMAIL PROTECTED] wrote: I think we shouldn't be too strict on user implementations of HasValue, but GWT widgets should be standardized. I agree with jat's comment that its okay to mutate the input from setValue(), and I agree with Isaac's comment that there are some times when the input is just not valid and it makes sense to throw an exception. My original inclination was that getValue() should return exactly what was set in setValue(), but I've changed my mind. In a traditional Java object, that would certainly be a good criteria. But UI widgets are interactive by nature. If I setValue() now, the end user can certainly interact with the widget such that getValue() returns a different result later. Sure we could say that a synchronous call to getValue() after setValue() should return the same value, but why bother when it isn't generally true? The side effect of this (this being we don't have tight correlation between getValue() and setValue()) is that we have some leeway in mutating the input of setValue(). For example, setValue(null) on a TextBox can clear the text, even though getValue() will return an empty string. Sure a TextBox doesn't technically have a null value, but I don't think anyone is really going to get confused if setValue() clears the text. 99% of the time, it will be obvious what setValue(null) does. Some widgets can mutate setValue() significantly. For example, an IntegerOnlyTextBox might convert all Strings to an intValue() and then back to a String. So far, we can now use HasValue widgets without any knowledge of the actual Widget. However, I think its acceptable for a widget to throw an exception if the value is completely invalid and can't be reasonably mutated (props to Isaac). It would be nice if GWT widgets accepted the entire range of values in all cases, but even that may be a stretch. For example, if we add a date range to DatePicker, it would be truly incorrect to set a date outside of that range (we could pick the closest much, but just go with the example). So, the user needs to have some knowledge of the underlying widget if she uses a widget that has some restrictions, but she only needs enough intel to know that the values coming from the magical source of values are compatible with the widget. If your magical source of values is trying to set invalid values and the Widget throws an exception, its probably a good thing. In the DatePicker example, you'd either need to fix the value, or expand the range. But, at least for GWT widgets, exceptions would be few and far between. Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Dec 1, 2008 at 7:47 PM, Isaac Truett [EMAIL PROTECTED] wrote: I share Ray's suspicion that this won't actually be much of a problem. A checked exception is clearly (I hope) the wrong way to go. Checked exceptions have their place, but they are a major pain in several anatomical locations when declared in situations where the vast majority of the time they cannot occur. On the other hand, unchecked exceptions for inputs that are unacceptable are quite normal (ArrayIndexOutOfBoundsException comes to mind). Nulls even have their own exclusive exception for unacceptability. Throwing exceptions like those can be left up to the individual HasValue implementation and developers will be accustomed to seeing and handling them. I think Ian's idea of a read-only interface is interesting, but not really on topic. Perhaps it deserves its own thread? On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher [EMAIL PROTECTED] wrote: As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue(null); The HasValue interface becomes a lot more difficult to implement if we insist that all non-null values are supported, it becomes slightly harder to use if we do not. So, which contract should we enforce? Proposal 1) setValue() gives no guarantee about whether a specific value is valid. Users must know the underlying widget is in order to safely use the HasValue interface. Proposal 2) setValue() will accept all non-null values of a specific
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
Yep. On Tue, Dec 2, 2008 at 11:23 AM, Ray Ryan [EMAIL PROTECTED] wrote: Trying to recap, I believe the concrete proposals I just heard are: 1. TextBoxBase should accept setValue(null), and return from getValue(); 2. It is reasonable for widgets that can't sensibly be cleared to throw IllegalArgumentException on setValue(null) 3. HasValue's javadoc should be tweaked accordingly Yes? rjrjr On Tue, Dec 2, 2008 at 6:12 AM, Emily Crutcher [EMAIL PROTECTED] wrote: This seems like the right philosophy to me, and your point about date pickers having an optional range is a very persuasive one, so I'm sold on the best guess with the widget being able to throw IllegalArgumentException as well. On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca [EMAIL PROTECTED]wrote: I think we shouldn't be too strict on user implementations of HasValue, but GWT widgets should be standardized. I agree with jat's comment that its okay to mutate the input from setValue(), and I agree with Isaac's comment that there are some times when the input is just not valid and it makes sense to throw an exception. My original inclination was that getValue() should return exactly what was set in setValue(), but I've changed my mind. In a traditional Java object, that would certainly be a good criteria. But UI widgets are interactive by nature. If I setValue() now, the end user can certainly interact with the widget such that getValue() returns a different result later. Sure we could say that a synchronous call to getValue() after setValue() should return the same value, but why bother when it isn't generally true? The side effect of this (this being we don't have tight correlation between getValue() and setValue()) is that we have some leeway in mutating the input of setValue(). For example, setValue(null) on a TextBox can clear the text, even though getValue() will return an empty string. Sure a TextBox doesn't technically have a null value, but I don't think anyone is really going to get confused if setValue() clears the text. 99% of the time, it will be obvious what setValue(null) does. Some widgets can mutate setValue() significantly. For example, an IntegerOnlyTextBox might convert all Strings to an intValue() and then back to a String. So far, we can now use HasValue widgets without any knowledge of the actual Widget. However, I think its acceptable for a widget to throw an exception if the value is completely invalid and can't be reasonably mutated (props to Isaac). It would be nice if GWT widgets accepted the entire range of values in all cases, but even that may be a stretch. For example, if we add a date range to DatePicker, it would be truly incorrect to set a date outside of that range (we could pick the closest much, but just go with the example). So, the user needs to have some knowledge of the underlying widget if she uses a widget that has some restrictions, but she only needs enough intel to know that the values coming from the magical source of values are compatible with the widget. If your magical source of values is trying to set invalid values and the Widget throws an exception, its probably a good thing. In the DatePicker example, you'd either need to fix the value, or expand the range. But, at least for GWT widgets, exceptions would be few and far between. Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Dec 1, 2008 at 7:47 PM, Isaac Truett [EMAIL PROTECTED] wrote: I share Ray's suspicion that this won't actually be much of a problem. A checked exception is clearly (I hope) the wrong way to go. Checked exceptions have their place, but they are a major pain in several anatomical locations when declared in situations where the vast majority of the time they cannot occur. On the other hand, unchecked exceptions for inputs that are unacceptable are quite normal (ArrayIndexOutOfBoundsException comes to mind). Nulls even have their own exclusive exception for unacceptability. Throwing exceptions like those can be left up to the individual HasValue implementation and developers will be accustomed to seeing and handling them. I think Ian's idea of a read-only interface is interesting, but not really on topic. Perhaps it deserves its own thread? On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher [EMAIL PROTECTED] wrote: As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue
[gwt-contrib] incubator code review
Code review request: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250 Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather then patching the widgetideas version, as this way we only maintain one version of DropDownPanel, which is going to be depricated as soon as the first 1.6 milestone is released. -- 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] Removing HasValue interface from gwt-incubator
John, Could you review this change? Unfortunately, HasValue from incubator directly conflicts with HasValue from gwt-trunk. Therefore creating a nasty path-dependency problem, the current solution is to remove HasValue from gwt-incubator: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1253 -- 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: incubator code review
The problem is that both versions on these widgets need to exist simultaneously for a period of time, to give our users enough space to move from the deprecated version to the non-deprecated one. For date picker, in specific, because it will be in the first 1.6 milestone, it does not seem worth people's time to migrate from widgetideas to the gen2 version at this late date, as while we will leave the date picker in gwt-incubator as a convenience, both versions will be deprecated within a matter of a couple of more weeks. On Tue, Dec 2, 2008 at 12:07 PM, Isaac Truett [EMAIL PROTECTED] wrote: Is that going to turn into a revolving door of new packages as each generation of widgets requires it's own namespace? It seems to me that the gen2 package idea was a mistake of convenience and maybe should have been a branch (or branches) that got merged back into trunk once it stabilized. On Tue, Dec 2, 2008 at 11:57 AM, John LaBanca [EMAIL PROTECTED] wrote: Is this a good idea? I think we should just deprecate the widgetideas version now in favor of the gen2 version. I didn't attempt to copy ScrollTable changes back to the widgetideas version, it would be a nightmare. IMHO, development on widgetideas code should be closed once a gen2 replacement is available. Thanks, John LaBanca [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 11:48 AM, Emily Crutcher [EMAIL PROTECTED] wrote: Code review request: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250 Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather then patching the widgetideas version, as this way we only maintain one version of DropDownPanel, which is going to be depricated as soon as the first 1.6 milestone is released. -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Fwd: Review of handler map speed test.
Joel, Thank you so much for looking into this! Below is the review request that was originally directed to Kelly. Also, I've cut/pasted the initial benchmark results I got from it. The way I interpret them is that we may/may not have a significant problem depending upon how many handlers programs actually have. As you can imagine, the fact that the string manipulation is globally slowed down if we don't use the flattened data structure is what most concerns me, as if this is a realistic number of handlers for a production system and this benchmark holds true, we would be slowing down this sort of string operation by over 90%. == Start handlerMapForSimpleJs Test== Creating 5000 handlerMapForSimpleJs maps 78 millseconds, 78 millseconds, 78 millseconds Adding 6 handlers for 5000 to a handlerMapForSimpleJs 312 millseconds, 266 millseconds, 329 millseconds Fired 3 handlers for 5000 widgets using handlerMapForSimpleJs 157 millseconds, 156 millseconds, 156 millseconds created a random string with 3 handlers using handlerMapForSimpleJs 156 millseconds, 203 millseconds, 219 millseconds == Start handlerMapForJs Test== Creating 5000 handlerMapForJs maps 78 millseconds, 94 millseconds, 109 millseconds Adding 6 handlers for 5000 to a handlerMapForJs 188 millseconds, 171 millseconds, 187 millseconds Fired 3 handlers for 5000 widgets using handlerMapForJs 157 millseconds, 157 millseconds, 172 millseconds created a random string with 3 handlers using handlerMapForJs 109 millseconds, 94 millseconds, 94 millseconds == Start handlerMapForJava Test== Creating 5000 handlerMapForJava maps 172 millseconds, 172 millseconds, 172 millseconds Adding 6 handlers for 5000 to a handlerMapForJava 453 millseconds, 453 millseconds, 469 millseconds Fired 36 handlers for 5000 widgets using handlerMapForJava 312 millseconds, 312 millseconds, 312 millseconds created a random string with 3 handlers using handlerMapForJava 141 millseconds, 188 millseconds, 188 millseconds -- Forwarded message -- From: Emily Crutcher [EMAIL PROTECTED] Date: Mon, Nov 17, 2008 at 2:50 PM Subject: Review of handler map speed test. To: Kelly Norton [EMAIL PROTECTED], Ray Ryan [EMAIL PROTECTED], Google Web Toolkit Contributors Google-Web-Toolkit-Contributors@googlegroups.com Kelly, Could you review this visual benchmark I was using to compute the pros/cons of the different handler maps? Of particular interest is the SimpleJsHandlerMap, to see if there is anything, well, simple we we can do to make it faster. http://code.google.com/p/google-web-toolkit/source/detail?r=4089 -- 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't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR: How absolute should the setValue's contract be?
As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue(null); The HasValue interface becomes a lot more difficult to implement if we insist that all non-null values are supported, it becomes slightly harder to use if we do not. So, which contract should we enforce? *Proposal 1) *setValue() gives no guarantee about whether a specific value is valid. Users must know the underlying widget is in order to safely use the HasValue interface. *Proposal 2) *setValue() will accept all non-null values of a specific type as valid input. In order to implement this, we will have to introduce HasClearValue to support clearing a widget. ListBox, for instance, would not be able to implement HasValueString, as not all strings would be valid inputs. -- 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: RR: How absolute should the setValue's contract be?
I'd prefer to leave the interface as is for now, and see if there is an actual problem here. I suspect we'll find ourselves in a world where most widgets deal with null, but string-based ones do not, and everyone will be just fine. Unfortunately, it is not very easy to change the contract after we've released it into the wild. We can go with either solution, as both have their plusses and minuses, but I'm not sure we can change course in the middle. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
On Thu, Nov 20, 2008 at 10:32 AM, Ray Ryan [EMAIL PROTECTED] wrote: Long term? 1.6, yes? On Thu, Nov 20, 2008 at 10:07 AM, Emily Crutcher [EMAIL PROTECTED] wrote: DateBox should implement the HasValue interface long term, which using the new terminology, does basically what you expect here. Yep, so long term may have been a bit of an exaggeration! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
On Thu, Nov 20, 2008 at 10:23 AM, John Tamplin [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 10:04 AM, Emily Crutcher [EMAIL PROTECTED] wrote: For efficiency and code clearity I would still be inclined to support the singleton version as well, but adding the Date... version as an option to the plural versions seems like a terrific idea. I don't think it matters if we use calendar/getCalendar, but we should probably pick only one for consistancy! You can still call the varargs version with a single value, as in addStyleToVisibleDates(styleName, date), and the extra cost should be minimal. I think the extra weight of additional API surface area is more costly. Well, we can always add the single-arg one back in, so if the compiler actually generates reasonably efficent code for this, I think you're probably right. -- John A. Tamplin Software Engineer (GWT), Google -- 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: Code review on date picker branch to date
Sorry, could have sworn that was public. Btw., DatePicker is littered with direct uses of the calendar field. If getCalendarView() is protected, we should always call it. Still, the amount of duplication btw. the DatePicker API and CalendarView is odd. Can CalendarView be reduced to a smaller set of primitive calls at all? E.g., it doesn't really need the setDatesEnabled convenience wrapper, DatePicker can be in charge of that kind thing. Sure, we can get rid of the convinience methods. So what is the actual date returned in such a case? The first day of the month(s) displayed? Or can a Date be filled with null day info? Sounds like another excellent javadoc opportunity. Yep. Also, I think it does make sense to extend this API down to the calendar model level, as that would probably help mitigate the confusion. Anyway, can such a CalendarView really be implemented? CalendarModel seems very locked down to a single month. The calendar view specifies a month at a time, the calendar view can increment the month to help it fill in its date views. That might not be possible--the compiler may find itself unable to tell whether to use the Date or the Date... version. Yep, and if we actually implement .. efficiently in our compiler, no reason to do this either! February is visible. The 10th is disabled. The user moves the picker to March, and back to February. What is the state of Feb. 10? It is no longer disabled. That's why the API has the assertion actually, as all the api calls that include visible dates specifically are reset when the date picker refreshes. Custom CalendarView seems okay, but MonthSelector is an empty class, and its default implementation is final. So I have protected API that says your month selector here, and no way to actually provide one without copying and pasting our code. That seems inconsistent. So you think we should include an extendable month selector as well? We actually even have a googler working on one, so we can see how far he has gotten or create one ourselves if he hasn't gotten far enough. CalendarUtil.java Some of the methods in this public class are not public, seemingly arbitrarily. Is there a real reason we don't want people to call isWeekend or hasTime? Why is resetTime private? We were trying to expose only the methods we were absolutely certain other people would want, mostely because we used them ourselves, rather then exposing all of them. If we have methods we aren't using, why are they there? We are using them for calendar model, we just don't know if anyone else would need to use them. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
Actually as Ray points out, foo(Bar) and foo(Bar...) are not distinguishable overloads, so you would have to reverse the order of the arguments to keep the single-arg version. One is plural, one is not, so they would hopefully not overlap at all. The bigger point though, is if the the compiler implements the .. sytax efficiently, no reason for the clutter. -- John A. Tamplin Software Engineer (GWT), Google -- 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: RR: Adding PopupPanel.showBelow
would have two methods: Showing a popup above the widget is very useful for cases when the popup shown below the widget will scroll the screen. In those cases it would be nice to be able to detect that the popup is going to show off the bottom of the screen and instead show it above the widget as a lot of toolkits do. Having an API method that easily allowed one to do this now would be quite helpful. Yep, that is what the current version does, it tries to show the popup below the ui object, but if it is too near the bottom of the screen, reverses itself. -- 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: RR: Adding PopupPanel.showBelow
It seems like that would be a good patch. It would belong on the gwt issue tracker. On Thu, Nov 20, 2008 at 11:30 AM, Isaac Truett [EMAIL PROTECTED] wrote: It certainly doesn't need to be a blocker on this change, but separating that popup/popdown logic so that we have our first two Orientation options would be handy (for writing a Windows-style Start menu, for example, that should always pop up and never down). Is this something that would be considered for the future (if, for example, someone submitted a patch...)? If so, which issue tracker does it belong in? On Thu, Nov 20, 2008 at 11:24 AM, Emily Crutcher [EMAIL PROTECTED] wrote: would have two methods: Showing a popup above the widget is very useful for cases when the popup shown below the widget will scroll the screen. In those cases it would be nice to be able to detect that the popup is going to show off the bottom of the screen and instead show it above the widget as a lot of toolkits do. Having an API method that easily allowed one to do this now would be quite helpful. Yep, that is what the current version does, it tries to show the popup below the ui object, but if it is too near the bottom of the screen, reverses itself. -- 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: Proposal: Extracting gwt-incubator-servlet.jar
shared - code that does not contain or reference any class that contains JSNI, GWT.create, or reflection I think this should be reachable code, in that code hiding behind a GWT.isClient() should be allowed. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
If the class is never loaded, how is it unsafe? On Thu, Nov 20, 2008 at 12:00 PM, John Tamplin [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 11:50 AM, Emily Crutcher [EMAIL PROTECTED] wrote: shared - code that does not contain or reference any class that contains JSNI, GWT.create, or reflection I think this should be reachable code, in that code hiding behind a GWT.isClient() should be allowed. No, because on some JVMs even the attempt to load a class that has native methods but no matching shared library (ie, JSNI) will thow an exception. I think the only safe way to make that work is with super-source overlaying the client-compatible version. -- John A. Tamplin Software Engineer (GWT), Google -- 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 -~--~~~~--~~--~--~---
