[gwt-contrib] Re: Adding ie7 and ie8 user.agent values?

On Thu, Dec 18, 2008 at 6:04 PM, Ray Cromwell wrote: > I floated an idea a long time ago of property aliasing/subtyping > (see here: > http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/8bd9fe0a2676c4a2) I like the aliasing idea, although how do you distinguis

[gwt-contrib] Re: Adding ie7 and ie8 user.agent values?

Apropos, I floated an idea a long time ago of property aliasing/subtyping (see here: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/8bd9fe0a2676c4a2) I proposed to this solve some problems with introducing new user.agent properties in the presence of third

[gwt-contrib] Re: Adding ie7 and ie8 user.agent values?

On Thu, Dec 18, 2008 at 1:44 AM, BobV wrote: > I wanted to float the idea of adding ie7 and ie8 values to the > user.agent property in trunk. Given that we collapse permutations > with identical rebind results before optimizing, adding them won't > cause an immediate increase in the total number

[gwt-contrib] Adding ie7 and ie8 user.agent values?

I wanted to float the idea of adding ie7 and ie8 values to the user.agent property in trunk. Given that we collapse permutations with identical rebind results before optimizing, adding them won't cause an immediate increase in the total number of permutations. Initially, all references to ie6 i

[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

[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,

[gwt-contrib] Re: Introducing DateBox.Format

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 Crutc

[gwt-contrib] Re: Introducing DateBox.Format

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 wrote: > Nope. > Each formatter

[gwt-contrib] [google-web-toolkit commit] r4353 - in releases/1.6/dev/core: src/com/google/gwt/core/ext src/com/google/gwt/dev src/com/goog...

Author: sco...@google.com Date: Wed Dec 17 16:14:23 2008 New Revision: 4353 Added: releases/1.6/dev/core/src/com/google/gwt/core/ext/ServletContainer.java (contents, props changed) - copied, changed from r4339, /releases/1.6/dev/core/src/com/google/gwt/dev/shell/ServletContaine

[gwt-contrib] Re: RR: PopupPanel#setAutoHidePartner

We could always add them later as well, if no one has a burning need for them. On Wed, Dec 17, 2008 at 5:58 PM, Ray Ryan wrote: > You mean replace setAutoHidePartner with add/removeAutoHidePartner? That > sounds reasonable, but I definitely don't have time. > rjrjr > > On Thu, Dec 18, 2008 at 3:

[gwt-contrib] Re: Introducing DateBox.Format

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 n

[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_DE

[gwt-contrib] Re: Introducing DateBox.Format

On Thu, Dec 18, 2008 at 9:58 AM, wrote: > thanks for the quick review! > > > http://gwt-code-reviews.appspot.com/1201/diff/1/2 > File > > reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForDateBox.java > (right): > > http://gwt-code-reviews.appspot.com/1201/diff/1/2#ne

[gwt-contrib] Re: RR: PopupPanel#setAutoHidePartner

You mean replace setAutoHidePartner with add/removeAutoHidePartner? That sounds reasonable, but I definitely don't have time. rjrjr On Thu, Dec 18, 2008 at 3:00 AM, Emily Crutcher wrote: > This seems like a very useful method to me. Should it be a singleton > though? As It would also be useful

[gwt-contrib] Re: Introducing DateBox.Format

thanks for the quick review! http://gwt-code-reviews.appspot.com/1201/diff/1/2 File reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForDateBox.java (right): http://gwt-code-reviews.appspot.com/1201/diff/1/2#newcode112 Line 112: startText.addKeyDownHandler(new KeyDown

[gwt-contrib] Re: Any objections to 1.5-final gwt-incubator drop going out this week?

+1 on the "Thanks Isaac!" sub-thread On Thu, Dec 18, 2008 at 3:11 AM, Emily Crutcher wrote: > 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

[gwt-contrib] Re: Introducing DateBox.Format

[+ contrib] Rietveld tip: If you give the issue title the same name as your RR thread's subject line, gmail will group them together. For that matter, you could have sent the RR message from Rietveld. rjrjr On Thu, Dec 18, 2008 at 9:41 AM, wrote: > This is big improvement. I think Format should

[gwt-contrib] Re: RR:IsFocusable interface

Yep, that's the plan! On Wed, Dec 17, 2008 at 5:10 PM, Ray Ryan wrote: > Works for me. And IsFocusable extends no other interfaces, right? > > > On Thu, Dec 18, 2008 at 7:18 AM, Emily Crutcher wrote: > >> The HasFocus interface extends SourcesFocusEvents and >> SourcesKeyboardEvents. The probl

[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 here. this interface has the following advantages: - As the date parsing is now completely replaceable, our default parser can be

[gwt-contrib] Re: RR:IsFocusable interface

Works for me. And IsFocusable extends no other interfaces, right? On Thu, Dec 18, 2008 at 7:18 AM, Emily Crutcher wrote: > The HasFocus interface extends SourcesFocusEvents and > SourcesKeyboardEvents. The problem is that users then must implement > SourcesFocusEvents and SourcesKeyboardEvents

[gwt-contrib] Issue 210 - demo index

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 --~--~-~--~~~---~--~~ http://groups.google.com/g

[gwt-contrib] [google-web-toolkit commit] r4352 - in releases/1.6/dev/core: src/com/google/gwt/dev test/com/google/gwt/dev

Author: sco...@google.com Date: Wed Dec 17 12:44:51 2008 New Revision: 4352 Modified: releases/1.6/dev/core/src/com/google/gwt/dev/HostedMode.java releases/1.6/dev/core/test/com/google/gwt/dev/HostedModeTest.java Log: Fixing Robert Vawter's build break. Modified: releases/1.6/dev/core

[gwt-contrib] [google-web-toolkit commit] r4351 - releases/1.6/user/src/com/google/gwt/user/tools

Author: sco...@google.com Date: Wed Dec 17 12:23:46 2008 New Revision: 4351 Modified: releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java releases/1.6/user/src/com/google/gwt/user/tools/Module.gwt.xmlsrc Log: Removing unsupported deploy-to attribute from generated pro

[gwt-contrib] RR:IsFocusable interface

The HasFocus interface extends SourcesFocusEvents and SourcesKeyboardEvents. The problem is that users then must implement SourcesFocusEvents and SourcesKeyboardEvents even for new widgets and cannot remove them without also removing the focusable contract. We cannot remove the SourcesFocusEvents

[gwt-contrib] Re: Making GWTShell/HostedMode testable; adding tests to verify command line options

TBR you @r4350. Slowpoke. On Fri, Dec 12, 2008 at 7:43 PM, Scott Blum wrote: > Hi Bob, > This is related to testing that the WAR design doc is being correctly > followed for options. > > http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6 > > The change to the main classes are to ma

[gwt-contrib] [google-web-toolkit commit] r4349 - releases/1.6/dev/core/src/com/google/gwt/dev/util/xml

Author: sco...@google.com Date: Wed Dec 17 10:39:51 2008 New Revision: 4349 Modified: releases/1.6/dev/core/src/com/google/gwt/dev/util/xml/ReflectiveParser.java Log: Fixes issue #3197; ignore DTDs in GWT modules. Found by: zundel Review by: spoon (desk) Modified: releases/1.6/dev/cor

[gwt-contrib] [google-web-toolkit commit] r4348 - releases/1.6/dev/core/src/com/google/gwt/dev/util/xml

Author: sco...@google.com Date: Wed Dec 17 10:32:43 2008 New Revision: 4348 Modified: releases/1.6/dev/core/src/com/google/gwt/dev/util/xml/ReflectiveParser.java Log: Update to Java 1.5. Modified: releases/1.6/dev/core/src/com/google/gwt/dev/util/xml/ReflectiveParser.java ==

[gwt-contrib] Re: HashMap keyset behavior

No, I'm sorry it appears as though this simple test does work. My real code is more complex and does return different results in hosted mode versus compiled. Perhaps it is a timing issue. I will repost if I find the issue. Thanks. On Dec 17, 12:38 pm, Scott Blum wrote: > You're saying this works

[gwt-contrib] Re: HashMap keyset behavior

You're saying this works in web mode and fails in hosted mode? On Wed, Dec 17, 2008 at 10:14 AM, todd.sei...@gmail.com < todd.sei...@gmail.com> wrote: > > In the following code web mode removes the object for key "foo1" but > hosted mode does not seem to remove it. What is the 'correct' > behavio

[gwt-contrib] Comment on ManagingMerges in google-web-toolkit

Comment by martin.trummer.76: sounds to me like you are doing a lot of things manually maybe SVN-merge.py could help you (http://www.orcaware.com/svn/wiki/Svnmerge.py) at least you would not have to manually track all your merge operations For more information: http://code.google.com/p/google

[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

[gwt-contrib] Re: Any objections to 1.5-final gwt-incubator drop going out this week?

+1. Let me know if I can assist with the transition. On Wed, Dec 17, 2008 at 10:25 AM, Emily Crutcher 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 g

[gwt-contrib] Re: RR: PopupPanel#setAutoHidePartner

This seems like a very useful method to me. Should it be a singleton though? As It would also be useful when creating, say, a cascading menu, to be able to add multiple auto hide partners. On Tue, Dec 16, 2008 at 5:04 PM, Ray Ryan wrote: > In the course of the DatePicker work, I added the setAu

[gwt-contrib] Re: HashMap keyset behavior

According to the JavaDocs of Map.keySet() the change should be reflected to the Map and the other way around. On Wed, Dec 17, 2008 at 4:14 PM, todd.sei...@gmail.com < todd.sei...@gmail.com> wrote: > > In the following code web mode removes the object for key "foo1" but > hosted mode does not see

[gwt-contrib] Re: Any objections to 1.5-final gwt-incubator drop going out this week?

Sounds good to me. -- Arthur Kalmenson On Wed, Dec 17, 2008 at 10:25 AM, Emily Crutcher 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-incubato

[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 deprecati

[gwt-contrib] HashMap keyset behavior

In the following code web mode removes the object for key "foo1" but hosted mode does not seem to remove it. What is the 'correct' behavior? I am using GWT 1.5.3. HashMap hm = new HashMap(); hm.put("foo1", new Foo()); Set keys = hm.keySet(); keys.remove("foo1"); --~--~-~--~~