Re: [gwt-contrib] Re: Comment on SoftPermutations in google-web-toolkit
I know it's early in the work day, but these spam comments are starting to get annoying. Could someone please ban/enable moderation/etc. after they get their coffee? :) Thanks! On Thu, Sep 15, 2011 at 9:44 AM, codesite-nore...@google.com wrote: Comment by pclog...@gmail.com: The best poker blog http://poker-blogs-see.**blogspot.comhttp://poker-blogs-see.blogspot.com Best PokerStars blog http://pokerstars-blogs.**blogspot.comhttp://pokerstars-blogs.blogspot.com Sexy, hot girls image http://china-sexy-girl-images.**blogspot.com/http://china-sexy-girl-images.blogspot.com/ For more information: http://code.google.com/p/**google-web-toolkit/wiki/**SoftPermutationshttp://code.google.com/p/google-web-toolkit/wiki/SoftPermutations -- http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Earn $1000-$2500 per month
And I, for one, appreciate the effort that goes into moderation! On that slightly off-topic note, I interact with the group via GMail 99.999% of the time, rather than the Groups UI. Does reporting spam messages in GMail translate to Groups at all? Or to put another way, GMail is smart enough to recognize that this is a mailing list when I mark something as spam and asks me if I want to unsubscribe. But is it smart enough to recognize that it is a Google Groups mailing list and send my spam flag to the Group moderation queue as well? There's no direct link from the message in GMail back to the Groups thread, so finding a message in Groups to spam flag it over there too is a relatively tedious manual task. I always sort of hoped the thought was being communicated for me. On Tue, Jun 7, 2011 at 12:32 PM, David Chandler drfibona...@google.comwrote: Nope, and I reject several spammers daily. On the GWT group, some have gotten smarter and are now posting legit-sounding messages in advance. /dmc On Tue, Jun 7, 2011 at 4:49 AM, roseanje...@rediffmail.com roseanje...@rediffmail.com wrote: Earn $1000-$2500 per month If you Register your name You Get Sign-up bonus $5 AND Get $.20 cent for each referral. Further details http://www.earnbyforex.com/index.php?id=35678365 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- David Chandler Developer Programs Engineer, Google Web Toolkit w: http://code.google.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Use glass panel isntead of alert() when displaying dev mode connection failures, (issue1449802)
Fred, I can't tell you how obnoxious this has been for me. When this change makes it into a release, I will owe you a beer or comparable gratuity. Thank you. On Tue, May 17, 2011 at 3:09 PM, fre...@google.com wrote: http://gwt-code-reviews.appspot.com/1449802/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Activities and Places documentation
GWT MVP Development with Activities and Placeshttp://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html does not, as far as I can see, contain any reference to the fact that you need to inherit com.google.gwt.activity.Activity and com.google.gwt.place.Place. Shouldn't it? Did I miss that being called out somewhere else? - Isaac -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
Thomas Broyer wrote: Finally, I don't really like the Widget suffix naming convention, that's what namespaces (packages in Java) are for (tell a Button from another Buton), but I sure could live with it. I already have those naming conflicts using Guava and gwt-dev –which includes a rebased, olderguava–, and some other library that transitively depends on a rebased Apache Commons, in the same project (so I have many Lists classes to choose from; not to mention java.util.List vs. jaa.awt.List, and java.util.Date vs. java.sql.Date). When I'm angry that eclipse always pick the wrong one by default, I configure it so it ignores the others when suggesting completions. Or maybe the GPE could plug into Eclipse to make it prefer the new Button so it's always displayed before the old one in such autocomplete or organize imports lists? +1 for right name, different package (and aggressive deprecation, please). On Thu, Feb 24, 2011 at 7:30 PM, Thomas Broyer t.bro...@gmail.com wrote: I support the overall idea. A few notes though: I'm worried about the events in the ButtonCell example. If they're just there to provide hooks to inject styles, then: you probably don't need them if you use a native button appearance; which means you're listening to events but doing nothing in response to them; and we now too many registered events are bad for performance (that's what lead to the event delegation pattern, taking advantage of event bubbling, right?) why couldn't you just use :hover, :active and similar pseudo-classes? OK, maybe the ButtonCell is not the best example, as its appearance and behavior are quite… limited, but still. Or could, in this case, the Appearance have hasHoverBehavior or similar that the Cell would use to decide which events it's interested in? (so if you want your onHover method to be called, you'd first have to override hasHoverBehavior to return true). As an alternative, a few such behaviours could come in mixin interfaces, and the Cell would advertise (in the javadoc) which ones it supports (the ButtonCell would then only say it handles mouseover events if the Appearance is an instanceof HasHover). You wrote: Finally, note that Appearance is an abstract class. This allows us to add more state logic in the future without breaking existing Appearances. For example, we could add new methods setRightFlush() and setLeftFlush() which would make the right and left edges of the button flat, such that they could be lined up next to each other. Existing appearances may not support the new feature, but they would still work. This is not exactly true: Since the new method is probably something obvious I might already have implemented it. This is really evil because my code might still compile but not work any more. — Source: https://groups.google.com/d/msg/google-guice/rV21c_HQivk/NLUNASfhHq8J See also in the same thread: https://groups.google.com/d/msg/google-guice/rV21c_HQivk/mI6JP206-tsJ You wrote: Some Cells support methods to change how the Cell is rendered. For example, ButtonCell could provide a setTabIndex() method to set the tab index of the element. ButtonWidget would expose the same methods and forward through to the Cell. Does it mean there could finally be a Button interface (implemented by both ButtonCell and ButtonWidget) as a few people have asked for: http://code.google.com/p/google-web-toolkit/issues/detail?id=5275 Finally, I don't really like the Widget suffix naming convention, that's what namespaces (packages in Java) are for (tell a Button from another Buton), but I sure could live with it. I already have those naming conflicts using Guava and gwt-dev –which includes a rebased, olderguava–, and some other library that transitively depends on a rebased Apache Commons, in the same project (so I have many Lists classes to choose from; not to mention java.util.List vs. jaa.awt.List, and java.util.Date vs. java.sql.Date). When I'm angry that eclipse always pick the wrong one by default, I configure it so it ignores the others when suggesting completions. Or maybe the GPE could plug into Eclipse to make it prefer the new Button so it's always displayed before the old one in such autocomplete or organize imports lists? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] incubator and compatability with gwt 2.1
There isn't one. Incubator is dead. On Thu, Sep 9, 2010 at 7:10 AM, Cameron Braid came...@braid.com.au wrote: What is the plan to bring incubator into compatability with gwt 2.1 ? Cheers Cameron -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I think that violates the spirit, if not the letter, of the addHandler() contract. I add a handler and I get back a HandlerRegistration. I can use that registration to remove the handler later, if I choose to do so. If I expose that registration to other code, then the other code can also remove the handler. But if I guard my registration jealously, I expect that nobody else will have the ability to remove my handler. It seems to me that canceling all of the old handlers when the manager changes is a recipe for hard to find bugs, especially if changing HandlerManagers is not a common use case. You're going to have handlers suddenly stop receiving events and not be able to find an explicit removal. On Thu, Feb 11, 2010 at 11:36 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: But what if you have the case where you're setting the HandlerManager specifically because you want to stop listening to all the events from the previous HandlerManager. The idea of a stack of HandlerManagers makes some sense if you want to have different HandlerManagers handling events for different parts of a system. I understand the idea of making your own HandlerManager, but from a design perspective, doesn't it make sense to just have a singleton HandlerManager? Are there performance implications of having everything go through one HandlerManager? All the best, -- Arthur Kalmenson On Wed, Feb 10, 2010 at 11:34 AM, Isaac Truett itru...@gmail.com wrote: The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while (am
not going to be generating the kinds of events that you are registered for),
why do you care if my mechanism for achieving that involves putting my usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are there already to turn off one type of event and
turn on another. The handlers for the off event don't fire because
their event simply doesn't happen. Then you don't have to worry about
which HM is active when a handler is added, making sure they get
removed properly, etc. Simpler, as you said.
On Thu, Feb 11, 2010 at 3:30 PM, Ray Ryan rj...@google.com wrote:
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps
in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g.,
to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal
createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
@John - No objection here. @Ray squared - The idea of overriding HandlerManager still intrigues me. I've never found myself wanting to do it and I don't recall seeing it in practice elsewhere. I'm curious. If either of you knows of a project where I could find an example, would you mind passing along a link? On Thu, Feb 11, 2010 at 4:52 PM, John LaBanca jlaba...@google.com wrote: Does anyone object to adding createHandlerManager now, and then adding getHandlerManager if it is needed later? Thanks, John LaBanca jlaba...@google.com On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: AutoHide PopupPanel on History Events
I like it except for one scenario: Say I have a GWT-powered eBook reader. I hide some navigation controls in the corner; mouse over and they pop up. I want them to disappear if you click outside the popup, so auto-hide=true. But If you click next page I want to set a history token (for the next page) and I want the controls to stay visible so that you don't have to mouse back over the trigger in the corner in order to flip the page again, or flip back. If auto-hide-on-click implied auto-hide-on-history then you would have to jump through some more hoops (keep track of the popup state and re-show after history change if it was visible before). On Wed, Jan 13, 2010 at 3:43 PM, j...@google.com wrote: An idea: What if we just considered auto-hide on history to be equivalent to auto-hide? I definitely see that we can't hide *all* popups on history events, but ones mark auto-hide seem like fair game. What do you think? http://gwt-code-reviews.appspot.com/132804 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: AutoHide PopupPanel on History Events
Take Ray's line of thinking one step further and have three methods? setAutoHideOnClick() setAutoHideOnHistory() setAutoHide() // Both of the above and any auto-hide-ish conditions identified later The constructor arg is passed to setAutoHide(). That makes sense in my head. Is that more confusing to anyone else? On Wed, Jan 13, 2010 at 4:08 PM, John LaBanca jlaba...@google.com wrote: So keep the new property, and set it true as a side effect of new Will it be confusing that it is a side effect of the constructor but not of setAutoHide()? Also, is it worth breaking existing code if we are providing a separate method anyway? I actually agree that its a good idea because its better for most users, but I'm just playing devil's advocate here. Let me know what you think and I'll prepare a final patch. Also, I don't think you need enabled in that property name. I can remove it. Thanks, John LaBanca jlaba...@google.com On Wed, Jan 13, 2010 at 4:03 PM, rj...@google.com wrote: On Wed, Jan 13, 2010 at 12:55 PM, Isaac Truett itru...@gmail.com wrote: I like it except for one scenario: Say I have a GWT-powered eBook reader. I hide some navigation controls in the corner; mouse over and they pop up. I want them to disappear if you click outside the popup, so auto-hide=true. But If you click next page I want to set a history token (for the next page) and I want the controls to stay visible so that you don't have to mouse back over the trigger in the corner in order to flip the page again, or flip back. If auto-hide-on-click implied auto-hide-on-history then you would have to jump through some more hoops (keep track of the popup state and re-show after history change if it was visible before). So keep the new property, and set it true as a side effect of new PopupPanel(true). For Isaac's eReader: PopupPanel panel = new PopupPanel(true); panel.setAutoHideOnHistoryEventsEnabled(false); Also, I don't think you need enabled in that property name. http://gwt-code-reviews.appspot.com/132804 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
Has everyone responding in this thread been checking the issue tracker, staring issues they want to see resolved, and entering new issues where they don't yet exist in the tracker? I know several of the requests mentioned in this thread are already in there. http://code.google.com/p/google-web-toolkit/issues/list On Fri, Dec 18, 2009 at 11:18 AM, Chris chrish...@gmail.com wrote: I would encourage any effort to get an instant compile feature in dev mode. When designing the GUI and tweaking a widget here or there or css, a quick turn around would be a huge win. Right now, tweaking the GUI is a cumbersome process. Chris On Dec 18, 10:16 am, Scott Blum sco...@google.com wrote: Thanks for the feedback Brad. We've talked internally about an idea for instant compile where the workflow would be essentially like hosted mode, except it would very quickly translate your code into JavaScript with zero optimizations. It sounds like there might be some interest in this. (Of course, we also want to make hosted mode much faster than it is even in 2.0!) On Fri, Dec 18, 2009 at 9:50 AM, Brad Leupen qcomps...@gmail.com wrote: Arthur, No, we are not closing DevMode. Our client app is not small. Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core workstation. Often, we are only able to refresh a handful of times before we start running into out-of-memory exceptions and browser crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in 2.0 is MUCH MUCH faster than before. We are very excited about this. However, I rarely need to use the debugger in the actual client. Most of the time I just want to refresh the layout or test the usability of a widget. For this, DevMode is overkill and, in fact, useless for testing real world UI latency. Draft Compile is a wonderful idea but even it takes over a minute to compile a single permutation of our app. At the end of the day, all i want to do is make a small change to a widget and refresh my browser to test the layout, look and feel, and usability. over and over and over. Sometimes i might need to debug my ui logic but not most of the time. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] now.. afetr GWT 2.0?
I'd like to see SuggestBox get a little love. For example: http://code.google.com/p/google-web-toolkit/issues/detail?id=2311 http://code.google.com/p/google-web-toolkit/issues/detail?id=2739 http://code.google.com/p/google-web-toolkit/issues/detail?id=3409 And one of those issues links to this thread where I had some other thoughts on SuggestBox improvements: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/83db777f0e0602d0 And if I could include a wish for future GPE development it would be wizards, automated refactorings, and reusable code templates. Things like: http://code.google.com/p/google-web-toolkit/issues/detail?id=3914 I already have at least one SuggestBox patch floating around out there. I'd be happy to update that and work on other SuggestBox features, too, in my spare time. If somebody with commit privs cares to buddy up for design and review, please feel free to contact me on or off list. :) Oh, and woohoo GWT 2.0! Go team! - Isaac On Wed, Dec 16, 2009 at 12:01 PM, Bruce Johnson br...@google.com wrote: Working on a draft one. What do folks here think is important? On Wed, Dec 16, 2009 at 7:42 AM, tfreitas tfrei...@gmail.com wrote: What about roadmap? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] TypeOracle allTypes including types not in a source path
+1 deprecate and warn. On Mon, Nov 23, 2009 at 2:24 PM, Ray Ryan rj...@google.com wrote: FWIW, this confusion is exactly why webAppCreator no longer generates projects that use the implicit include. I wonder if we shouldn't flat out deprecate it--in which case a warning would be the right thing. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dev mode Swing UI horizontal scrolling
I agree that SwingLoggerPanel hasn't changed, but something related must have changed. I've just fired up dev mode from trunk (updated within the last 24 hours) and the upper panel scrolls while the lower panel line wraps. Maybe an unintentional result of some other change since MS2. Regardless, I'm quite happy with the way it works in trunk and don't feel a need to investigate any further. Thank you, Chris and John. Sorry for the false alarm! - Isaac On Fri, Nov 20, 2009 at 10:20 AM, John Tamplin j...@google.com wrote: On Fri, Nov 20, 2009 at 10:15 AM, Chris Ramsdale cramsd...@google.com wrote: I'll see if I can reproduce this using RC1 and get back to you shortly. There have been no changes in RC1 for that. On Fri, Nov 20, 2009 at 9:14 AM, Isaac Truett itru...@gmail.com wrote: I've noticed that the Swing UI for dev mode is missing horizontal scroll bars. That is, if you have an item in the log tree or details in the panel below that exceed the width of the window, there's no way to scroll over and read the text. I've tested this in MS2. Can anyone verify if this problem still exists in RC1? I probably won't have a chance to install RC1 and try it out until later this weekend. It has been a long time since I did that, but IIRC the code that does that is SwingLoggerPanel.java:373, and I couldn't find a way that allowed horizontal scrolling and auto-resized the details pane. I haven't done much with Swing, so I am sure there is a better way to do this -- patches welcome :). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Dev mode Swing UI horizontal scrolling
All, I've noticed that the Swing UI for dev mode is missing horizontal scroll bars. That is, if you have an item in the log tree or details in the panel below that exceed the width of the window, there's no way to scroll over and read the text. I've tested this in MS2. Can anyone verify if this problem still exists in RC1? I probably won't have a chance to install RC1 and try it out until later this weekend. Thanks, Isaac -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Google Web Toolkit 2.0 RC1 Now Available
Woo! Go team! I've been using MS2 on an old 1.4 app that I'm updating. Upgrade was smooth. New dev mode is great. Looking forward to trying RC1 now with the Eclipse plugin update. Thanks! On Tue, Nov 17, 2009 at 2:13 PM, Bruce Johnson br...@google.com wrote: Hi folks! GWT 2.0 RC1 is now ready for you to try. The full documentation is still very much a work in progress, but you can at least start trying out the GWT SDK distribution and the Google Plugin for Eclipse using the following instructions: http://code.google.com/p/google-web-toolkit/wiki/GWT_2_0_RC GWT 2.0 is going to be a big release, so don't be surprised if there are a few bumps and surprises as we continue to finalize everything. Similarly, we would caution you against using GWT 2.0 RC1 in production. We are eager to get your feedback, both good and bad, in the Google Web Toolkit Developer Forum: http://groups.google.com/group/google-web-toolkit If you find specific bugs to report, please do so in the GWT Issue Tracker: http://code.google.com/p/google-web-toolkit/issues See you online. Happy coding :-) -- Bruce, on behalf of the GWT team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Server side I18N
The idea of having some permutations resolved JIT and cached sounds great! I would expect more differences than just directionality, but I have no idea how many. What about John's plural example, for instance? That's more than a localized string replacement. On Tue, Oct 20, 2009 at 10:46 AM, Ray Ryan rj...@google.com wrote: The 40+ languages situation really is unpleasant, and has lead us to devote a lot of time to squeezing every last ounce of performance out of the compiler. We've pitted our desire to let the compiler spend time optimizing code against the need to get things built in a reasonable amount of time, and we're in a continual struggle on the reasonable amount of time side. How have we convinced ourselves that a tight binary requires a permutation per language? Wouldn't a permutation per direction (rtl v.ltr) plus load time stitching of locale resources work just as well in the browser? It's not like loading the resources would have to happen via a separate browser request, they could be blended with the rest of the code by the server at request time. I think I just suggested that the cache*html files become a template, with tokens swizzled for localized strings and data urls post compile, perhaps on demand. That sounds different than a linker to me--is it? rjrjr On Tue, Oct 20, 2009 at 6:59 AM, John Tamplin j...@google.com wrote: On Tue, Oct 20, 2009 at 4:24 AM, Thoka thobias.karls...@gmail.com wrote: The initial problem was due to compile time and permutations. We just launched a GWT application with 43 languages, which generates about 43*6(?) permutations, and to get 43 languages (where each language has about 800 text and 300 configuration properties) entirely correct, this would generate a whole bunch of extra builds and server downtime each time a country wants to change even a very small thing as a misspelling. Perhaps this is not very useful when an application is perfectly in shape, configured and all texts are flawless, but while in developing/staging state it has saved us weeks of development since the customer is now able to internationalize their application live at staging/pre-prod state via an I18N-servlet, without the need to translate blindly and wait for the re-build and re-deploy for each batch. Perhaps this is not a feature for the common GWT developer, but as stated, it is very nice to have for larger applications. I agree the situation you describe is an issue. A few points: Doing a release build, with all the localizations, should only need to be done when you are actually pushing a new build to production. All your work can be done with a different module that limits the number of locales (and user agents, depending on what sort of work you are doing) during development. GWT is designed for parallel compilation. If you have a compile cluster, you can build all the permutations in parallel so that the overall build time is the same as one permutation if you have enough machines. Instead of calling the Compiler entry point, you run Precompile on the main node, then CompilePerms on each permutation (they can all be run in parallel), and then Link after all permutations have finished. If the nodes don't share a common filesystem, you have to do the work to copy the precompilation.ser file to the permutation nodes and get all the artifacts back from them to the main node. You also have to provide some glue for your cluster/build system to make this happen, but the basic support is there. Eventually we will probably provide more assistance in this area. Lex is working on changes to the Link phase which should (in theory) allow incremental linking -- you could recompile just the permutation you need to change and link it with the results of a previous compile, so if all you did was to change the German translations you could just rebuild those permutations to get your compiled output. So, basically I agree that this is an issue but I think the best solution is not to throw out compile-time evaluation/optimization but instead to use the existing tools for parallel compilation, and for us to continue to improve those tools. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: break up our too-large RPCSuite
(@GWTC, even if successful, this is unlikely to help most external users, unless you happen to have an extra hundred machines available for a test run. Sorry. It should, however, let us break you less often, if only by shortening the build/test cycle of the robot builder.) Now if only there were a huge server farm somewhere with a little spare CPU time to act as a build/test robot for the rest of us. Say, something that ran Python and Java web apps. Wouldn't that be awesome? ;D --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Adds parsers for Dock Stack layout panels. Updates Mail sample to use UiBinder.
Hey guys,
The autoformater will change this to
@UiField
Button closeButton;
which sucks. I want to fix that for annoations with no arguments, but
have no
idea how to. You have any clue to share?
Bugs the crap out of me too. I can't find any annotation-related
settings in the code formatter, unfortunately.
Just in case you didn't see this: in Eclipse 3.5 (I haven't looked at
earlier versions) there's an Annotations section on the New Lines tab.
That will let you remove the new lines after annotations, but it
doesn't let you decide based on whether or not the annotation has
arguments.
- Isaac
On Tue, Sep 22, 2009 at 4:50 PM, j...@google.com wrote:
http://gwt-code-reviews.appspot.com/68805/diff/1/3
File samples/mail/src/com/google/gwt/sample/mail/client/AboutDialog.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/3#newcode38
Line 38: @UiField Button closeButton;
On 2009/09/22 20:12:42, Ray Ryan wrote:
The autoformater will change this to
�...@uifield
Button closeButton;
which sucks. I want to fix that for annoations with no arguments, but
have no
idea how to. You have any clue to share?
Bugs the crap out of me too. I can't find any annotation-related
settings in the code formatter, unfortunately.
http://gwt-code-reviews.appspot.com/68805/diff/1/8
File samples/mail/src/com/google/gwt/sample/mail/client/Mail.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/8#newcode68
Line 68: // Add the outer panel to the RootPanel, so that it will be
On 2009/09/22 20:12:42, Ray Ryan wrote:
RootLayoutPanel
Done.
http://gwt-code-reviews.appspot.com/68805/diff/1/10
File samples/mail/src/com/google/gwt/sample/mail/client/MailDetail.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/10#newcode44
Line 44: subject.setInnerHTML(item.subject);
On 2009/09/22 20:12:42, Ray Ryan wrote:
Should put a comment here explaining how shockingly dangerous it would
be to
take user provided text as innerHTML in a production app for XSS
reasons, and
that we're assuming that our server has done the appropriate escaping.
Done.
http://gwt-code-reviews.appspot.com/68805/diff/1/13
File samples/mail/src/com/google/gwt/sample/mail/client/MailList.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/13#newcode236
Line 236: table.setHTML(i, 0, nbsp;);
On 2009/09/22 20:12:42, Ray Ryan wrote:
ditto
These are static strings, which are always safe.
http://gwt-code-reviews.appspot.com/68805/diff/1/16
File samples/mail/src/com/google/gwt/sample/mail/client/Shortcuts.ui.xml
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/16#newcode24
Line 24: g:header size='4'g:Label styleName='{style.stackHeader}'
text='Mailboxes'//g:header
On 2009/09/22 20:12:42, Ray Ryan wrote:
g:header size='4'g:Label styleName='{style.stackHeader}'
Mailboxes
/g:Label//g:header
and likewise below
Done.
http://gwt-code-reviews.appspot.com/68805/diff/1/24
File user/src/com/google/gwt/uibinder/parsers/DockLayoutPanelParser.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/24#newcode82
Line 82: writer.die(Child must be one of {north, south, east, west,
center});
On 2009/09/22 20:12:42, Ray Ryan wrote:
writer.die(In %s, child must be one of {north, south, east, west,
center},
elem);
here and below and throughout the parsers
Also, is it legal to have more than one child of a particular
direction?
die(): done.
It is indeed legal to have more than one widget in a direction, in any
order.
http://gwt-code-reviews.appspot.com/68805/diff/1/24#newcode88
Line 88: writer.die(Dock must contain a single child widget.);
On 2009/09/22 20:12:42, Ray Ryan wrote:
redundant, this check is performed by consumeSingleChildElement
Done.
http://gwt-code-reviews.appspot.com/68805/diff/1/25
File
user/src/com/google/gwt/uibinder/parsers/StackLayoutPanelParser.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/25#newcode80
Line 80: return child.getNamespaceUri().equals(parent.getNamespaceUri())
On 2009/09/22 20:12:42, Ray Ryan wrote:
We need to bake this into an AbstractElementParser, don't we?
Probably so. Would have been useful. Next time around...
http://gwt-code-reviews.appspot.com/68805/diff/1/28
File user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
(right):
http://gwt-code-reviews.appspot.com/68805/diff/1/28#newcode191
Line 191: public void insertEast(Widget widget, double size, Widget
before) {
On 2009/09/22 20:12:42, Ray Ryan wrote:
It's all of these insert methods that made me think you'd be better
off allowing
only a single widget in each position.
Perhaps, but it's still pretty useful to have any number of them. The
insert() case is kind of annoying to write from my end, but it's pretty
useful from the developer's end.
http://gwt-code-reviews.appspot.com/68805
--~--~-~--~~~---~--~~
[gwt-contrib] Re: GWT Incubator compatibility policy
I am confident that r6108 fixed the problem I was having with GWT trunk last night. I think I just happened to try to build during a brief period where the build had broken. By the time r6108 had been committed, I had already moved on to other things. I see what you're saying about incubator being bogged down by backwards compatibility. I had thought of incubator more as a place to develop new APIs rather than a place to build on pre-release APIs. The issue as it sounds to me is that when a new API develops outside of incubator (such as in GWT trunk), you want to develop/update incubator widgets with that API before it gets into a GWT milestone. Would a branch for 1.7 really help with the morass problem? If you maintain the branch, then you still have to code incubator changes against two different versions of GWT. If you don't maintain the branch, then it's not particularly useful. Going forward should the advice be don't use incubator unless you plan to stay at the bleeding edge of GWT trunk? I can't speak for other developers, but if that had been the case then I don't think I would've ever used incubator widgets in my work projects. Maybe I shouldn't have used them, but they've been very helpful so far. None of the widgets have been production quality to begin with, but I've been able to report bugs and get bug fixes committed, sometimes supplying fixes myself, and build from incubator trunk without worrying that I'd have to update my GWT core to a trunk build. Losing that assurance will hurt, but it won't be the end of the world. It will definitely make it harder for me to benefit from the latest incubator widget bug fixes. On Thu, Sep 10, 2009 at 11:44 AM, Ray Ryan rj...@google.com wrote: I built incubator against trunk last night. Are you still seeing trouble there? The problem on our end has been that having to maintain code that works both with trunk and with the previous release makes it very difficult to iterate rapidly on incubator code. What was supposed to be a place that we could rapidly develop new features instead turns into a morass where forward progress is twice as hard a normal. That's why UiBinder in particular never moved to incubator. Our expectation is that new features will be either developed directly in trunk (e.g. UiBinder), or else in separate projects on code.google.com that can determine their own policies on compatibility and contributors (e.g. Gin). The items that live in incubator already will either gradually move to trunk or languish. It sounds like we need to think a bit harder how to handle the stuff that hasn't graduate yet, but which is still in use. My knee jerk is to cut a 1.7 branch just before the patch that killed off StyleInjector. How does that sound? rjrjr On Thu, Sep 10, 2009 at 8:28 AM, Isaac Truett itru...@gmail.com wrote: [oops - +gwtc] Hi, Ray, I appreciate the drive to move forward and I applaud jumping on opportunities to remove redundant code. The reason this policy was important, to me at least, is that it provided a baseline to work against. The code in the incubator can be very useful (I use PagingScrollTable extensively and used DatePicker from incubator before it graduated) but it's also risky because the code is still experimental and subject to change. The assurance that those changes would be compatible with a packaged and released GWT build (even just a milestone) meant that I could build incubator from trunk and pick up the latest features and bugfixes as long as my project tracked the latest GWT build. Because of the GWT policies on deprecation and backwards compatibility, this has been fairly easy in practice. As it stands now, incubator will not compile except against GWT trunk, which is also notoriously unstable (it wasn't building as recently as last night, which I see was corrected this morning). This presents a much higher risk for those of us using incubator code. It also becomes harder to work on the incubator itself when it has to compile against GWT trunk. I wanted to look into issue #267 last night and I was stymied by GWT trunk not being in a buildable state. Not an insurmountable obstacle, but one that seems unnecessary to me. - Isaac On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan rj...@google.com wrote: Hey, Isaac. That policy has proven very difficult to live with. (And to tell you the truth I forgot about it.) The reasoning here was that we have released incubator jars that work with 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it prove necessary to go back and do so we can go back and branch. In the meantime, we were faced bugs due to FastTree in particular being tied to the old StyleInjector while new development was moving to the version in GWT. We saw the opportunity to delete redundant code and took it. Is this going to cause problems for anyone? rjrjr On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett itru
[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases
-- Example #1 -- Please sort the following two lists chronlogically as quickly as you can: List 1: 1.6.2, 1.6.5, 1.6.0, 1.6.1 List 2: 2.0.0-rc2, 2.0.0-ms2, 2.0.0, 2.0.0-rc1 This should be trivial for anyone familiar with the concepts of milestone and release candidate builds. Anyone not familiar with those concepts shouldn't be using those builds, IMO. It's a little harder for a computer but they don't mind doing the extra work, really. My beef with the current system is that it doesn't clearly distinguish between releases and candidates/milestones. May I propose the following alternative for picking apart? major.minor.bugfix.svn-revision.[rc|m|r]n where 'r' denotes a release. That would disambiguate and sort easily. On Thu, Aug 13, 2009 at 2:31 PM, Scott Blumsco...@google.com wrote: On Wed, Aug 12, 2009 at 6:39 PM, Bruce Johnson br...@google.com wrote: Senator Blum, Do you mean disturbing as in 1) revolting, 2) distressing, or 3) disordering? Distressing, I think. -- Example #1 -- Please sort the following two lists chronlogically as quickly as you can: List 1: 1.6.2, 1.6.5, 1.6.0, 1.6.1 List 2: 2.0.0-rc2, 2.0.0-ms2, 2.0.0, 2.0.0-rc1 -- Example #2 -- uberuser: There's a bug in GWT where tab panels explode on FF3. gwtcoder: What version are you using? I fixed that in 2.0.0. (+Status:Duplicate) uberuser: I'm using 2.0.0 and it's still broken. gwtcoder: Okay I'll take a look (-Status:Duplicate, +Status:Accepted) gwtcoder: I can't repro this in 2.0.0. Are you sure you're using the 2.0.0 RELEASE and not 2.0.0-rc1 or 2.0.0-ms2? (-Status:Accepted, +Status:NeedsInfo) uberuser: Doh! You're right, I was using 2.0.0-rc1. After upgrading to 2.0.0 RELEASE and recompiling, the problem went away. Sorry, thanks! gwtcoder: No prob, our version numbers are admittedly a bit confusing. (-Status:NeedsInfo, +Status:Duplicate) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases
This reminds me of a thread I saw recently on whether the value 1 in a foo_percentage database column meant 100% or 0.01%. And on topic, +1 for the new version names. Has anyone talked to the maven crowd about this? They seem to usually have an opinion on naming schemes. On Wed, Aug 12, 2009 at 9:35 AM, Bruce Johnsonbr...@google.com wrote: Duh, Kelly. Everybody knows that you always start counting at 1 when there's a number immediately following a space or a non-digit and you start counting at 0 when there's a number that immediately follows a period. It's such a logical and obvious system that I thought the rules would be self-evident. On Wed, Aug 12, 2009 at 9:24 AM, Kelly Norton knor...@google.com wrote: No, no, Joel, we will start counting at 1 not 0. The first release will be gwt-2.1.1-m1. I think the naming scheme is good (even if sometimes starts with 0, other times with 1). /kel On Wed, Aug 12, 2009 at 9:12 AM, Joel Webber j...@google.com wrote: Makes sense to me. So the first one will be gwt-2.0.0-m0, right? On Tue, Aug 11, 2009 at 11:40 PM, Bruce Johnson br...@google.com wrote: Mostly, this writeup is aimed at people who have been working on GWT's own build-related stuff, but if anyone else has objections, now would be a good time to raise them (though it seems unlikely anyone would). In the past, we've never had a good naming scheme for distros other than the general availability distro. For milestones, we used the convention 0.0.rev, which probably scares people off and isn't at all self-descriptive. For RCs and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing. Here's the new proposal: major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2) = This is an official, supported build. Every new minor (or bigger) release would start with a bugfix number of 0. major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2) = This is release candidate build n for the specified upcoming GWT release major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2) = This is milestone build n for the specified upcoming GWT release In other words, the stream of announced code drops for 2.0 will look like this (assuming 2 milestone and 1 rc): 1) gwt-2.0.0-m1.zip 2) gwt-2.0.0-m2.zip 3) gwt-2.0.0-rc1.zip 4) gwt-2.0.0.zip Note that we would always include the RC number, even if there's just one (because you never know if another one is coming). I'm very happy to report that there seems to be no need to change even a single line of code, as best I can tell. (Thank you to whomever wrote the version string parsing code to ignore non-digit prefixes and suffixes.) Thus, by simply following this convention when we set GWT_VERSION in the continuous build, everything should work just fine. -- Bruce P.S. No, Joel, we can't start counting at 0, even though it makes more sense :-) I can read your mind. -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Any hints on why GWT's JUnit tests would be consistently timing out for me?
I'm trying to run the unit tests in GWT trunk. I've tried with Ant and with the JUnit UI in Eclipse, but I'm seeing many of the suites exceed the 60 second timeout: [junit] - 1 client(s) haven't responded back to JUnitShell since the start of the test. I'm at a loss to figure out what it's waiting on. I've sat and watched my CPU usage and it isn't anywhere near topping out for the minute it takes the test to time out. I've tried running just a single test class or a single method using the Eclipse UI and even a do-nothing test times out. I'm assuming it's something wonky on my end. Anyone have any suggestions? Thanks, Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Any hints on why GWT's JUnit tests would be consistently timing out for me?
Matt, Actually I'm running under Win XP (with IE 6) right now. I tried with -notHeadless and I didn't see any prompts. The test finished normally. I then removed -notHeadless and the test timed out again. So, thank you! I still don't know why it is timing out in headless mode, but at least I can make the test run now. - Isaac On Sat, Aug 8, 2009 at 2:56 PM, Matt Mastraccimatt...@mastracci.com wrote: Issac, Are you running under Linux? If so, your embedded Mozilla browser may be showing a prompt, but its window is hidden. Try running with - notHeadless. On 2009-08-08, at 11:55 AM, Isaac Truett itru...@gmail.com wrote: I'm trying to run the unit tests in GWT trunk. I've tried with Ant and with the JUnit UI in Eclipse, but I'm seeing many of the suites exceed the 60 second timeout: [junit] - 1 client(s) haven't responded back to JUnitShell since the start of the test. I'm at a loss to figure out what it's waiting on. I've sat and watched my CPU usage and it isn't anywhere near topping out for the minute it takes the test to time out. I've tried running just a single test class or a single method using the Eclipse UI and even a do-nothing test times out. I'm assuming it's something wonky on my end. Anyone have any suggestions? Thanks, Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: PopupPanel.center() places large content partially off-screen
Joel, Same fix, but with a unit test. - Isaac On Tue, Aug 4, 2009 at 9:25 PM, Isaac Truettitru...@gmail.com wrote: Joel, The patch is attached. I wanted to write you a JUnit test to go with it, but I'm having trouble even getting the existing tests to run. I did verify this fix manually. Thanks, Isaac On Tue, Aug 4, 2009 at 3:22 PM, Isaac Truettitru...@gmail.com wrote: Thanks, Joel. I'll see if I can put something together tonight. On Tue, Aug 4, 2009 at 3:12 PM, Joel Webberj...@google.com wrote: Sounds like a bug to me. It's hard to imagine how this behavior could be considered useful. I would assume the appropriate behavior would be to center, but keep the top-[left right] on the screen, depending upon the RTL mode. Can anyone see a problem with this? @Isaac: If you feel like writing up a patch, I'd be happy to review. On Tue, Aug 4, 2009 at 2:49 PM, Isaac Truett itru...@gmail.com wrote: I've just noticed that when the content of a PopupPanel grows larger then the browser window, center() can position the panel with a negative top/left, making part of the panel unreachable (the window won't scroll up or left anymore to see the off-screen portion). Is this considered a feature of the center() method? If so, would people be open to adding an overloaded center(boolean dontGoOutOfBounds) that would keep the top and left from going negative, assuming a better name for the argument could be found? - Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- PopupPanel-center.patch Description: Binary data
[gwt-contrib] PopupPanel.center() places large content partially off-screen
I've just noticed that when the content of a PopupPanel grows larger then the browser window, center() can position the panel with a negative top/left, making part of the panel unreachable (the window won't scroll up or left anymore to see the off-screen portion). Is this considered a feature of the center() method? If so, would people be open to adding an overloaded center(boolean dontGoOutOfBounds) that would keep the top and left from going negative, assuming a better name for the argument could be found? - Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: PopupPanel.center() places large content partially off-screen
Thanks, Joel. I'll see if I can put something together tonight. On Tue, Aug 4, 2009 at 3:12 PM, Joel Webberj...@google.com wrote: Sounds like a bug to me. It's hard to imagine how this behavior could be considered useful. I would assume the appropriate behavior would be to center, but keep the top-[left right] on the screen, depending upon the RTL mode. Can anyone see a problem with this? @Isaac: If you feel like writing up a patch, I'd be happy to review. On Tue, Aug 4, 2009 at 2:49 PM, Isaac Truett itru...@gmail.com wrote: I've just noticed that when the content of a PopupPanel grows larger then the browser window, center() can position the panel with a negative top/left, making part of the panel unreachable (the window won't scroll up or left anymore to see the off-screen portion). Is this considered a feature of the center() method? If so, would people be open to adding an overloaded center(boolean dontGoOutOfBounds) that would keep the top and left from going negative, assuming a better name for the argument could be found? - Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: PopupPanel.center() places large content partially off-screen
Joel, The patch is attached. I wanted to write you a JUnit test to go with it, but I'm having trouble even getting the existing tests to run. I did verify this fix manually. Thanks, Isaac On Tue, Aug 4, 2009 at 3:22 PM, Isaac Truettitru...@gmail.com wrote: Thanks, Joel. I'll see if I can put something together tonight. On Tue, Aug 4, 2009 at 3:12 PM, Joel Webberj...@google.com wrote: Sounds like a bug to me. It's hard to imagine how this behavior could be considered useful. I would assume the appropriate behavior would be to center, but keep the top-[left right] on the screen, depending upon the RTL mode. Can anyone see a problem with this? @Isaac: If you feel like writing up a patch, I'd be happy to review. On Tue, Aug 4, 2009 at 2:49 PM, Isaac Truett itru...@gmail.com wrote: I've just noticed that when the content of a PopupPanel grows larger then the browser window, center() can position the panel with a negative top/left, making part of the panel unreachable (the window won't scroll up or left anymore to see the off-screen portion). Is this considered a feature of the center() method? If so, would people be open to adding an overloaded center(boolean dontGoOutOfBounds) that would keep the top and left from going negative, assuming a better name for the argument could be found? - Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- PopupPanel-center.patch Description: Binary data
[gwt-contrib] Re: NOTICE - removing all @deprecated code for GWT 2.0
Woo and, may I say, hoo, for removing deprecated code. Will deprecated code in the Incubator be disappearing as well? Obviously if that deprecated code depends on deprecated GWT code, it will at least have to be updated. On Fri, Jul 31, 2009 at 12:22 PM, Fred Sauerfre...@google.com wrote: To all GWT contributors- As you may know, there many exciting things we're working on for GWT 2.0. With all the new features coming your way we thought GWT 2.0 would be a good opportunity to clean house and remove previously deprecated methods and classes. In many cases an equivalent replacement is suggested in the Javadoc and updating your projects should hopefully not be too onerous. While different sections of the API have been deprecated in different releases we wanted to make things as straightforward as possible for the upcoming release. As such, our plan for GWT 2.0 is to remove everything that was marked as deprecated in previous releases. We did not introduce any new deprecations in GWT 1.7 so you can find the complete list of items we plan to remove in this GWT 1.6 document: http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/deprecated-list.html If you have any serious concerns about the above deprecation list, please reply back to indicate how you will be affected. In particular I'm interested in any use cases in the GWT 1.6/1.7 API which you feel would not be covered in GWT 2.0 once the @deprecated methods and classes have been removed. Please note that Java compilers are required to warn you when your code uses @deprecated methods or classes. Although there are warning suppression mechanisms such as the @SuppressWarnings annotation and your IDE's or build environment's settings. So, in general, chances are you are probably not using any deprecated GWT APIs without knowing about it. Thanks-- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: More interfaces part 2
A very good write-up, Joel. I especially like that you mentioned the union types. I recently discovered them myself, in that I found myself wanting a FooAndBar interface and I realized that just such a union was possible without actually declaring a new interface. It seems to be a pretty low profile feature. Thanks for sharing! On Thu, Jul 23, 2009 at 9:49 AM, Joel Webberj...@google.com wrote: I'm bringing this back up again because of a recent ping to an issue-tracker entry about more interfaces. I understand your pain, but these are issues with the Java language which we've discussed at length in the past, and to my knowledge reached no substantive conclusions other than: - A few more interfaces in very specific places (e.g., InsertPanel) would be useful. - We can't run off and create custom interfaces for the cross-product of every characteristic interface and have every widget implement them. It turns into a permutation explosion of interfaces. If java had some kind of trait system or implied interfaces the story would be different, but alas, we're stuck with it the way it is for the foreseeable future. Making Widget an interface (IWidget?) sounds appealing in theory, for reasons you describe, but there are also very good reasons for leaving it as a concrete base class. This has come up often enough that I just created a wiki page explaining precisely why Widget is an abstract base class as opposed to an interface here: http://code.google.com/p/google-web-toolkit/wiki/WhyWidgetIsAClass On Fri, Apr 3, 2009 at 6:00 AM, Ed post2edb...@hotmail.com wrote: Hellu, I would like to know whtat the current status is of incoparating more basis interface in GWT? We talked about this a long time ago, but there more important issues then: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/2aad0c3459e2c7f/cd59f6b35714ed31?lnk=gstq=more+interfaces I still keep on bouncing my head against these kind of interface issues: Below another example, which I hope would give some more priority to the issue: I need a general TextWidget that extends/implements from Widget and implements HasText, HasHtml. I thought I could easily solve this with Generics... Not.. really (see below). I want to return a Widget as result of a method that creates a Widget that implements HasHtml/HasText. I tried something like this: W extends Widget HasText HasHTML CmsFormatResultTextW create (String item); But calling this method isn't possible as the compiler complaints that Widget isn't a valid substitute. Body example: return new HTML(aaa); Which isn't correct as the compiler also complaints about not able to convert HTML to W... To solve this, I think I need a basis Widget interface instead of a Widget class. Please some feedback/advice on this. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal for improving JDO/JPA RPC support
5) When the object is sent back to the server, the normal RPC mechanism is altered as follows a) the encoded server data is decoded and deserialized into the new object instance b) the client data is populated using setXXX() method invocations rather than by directly setting field values Is this introducing a requirement that all serializable fields have setters? Or will direct field access be used where a setter can't be found? On Mon, Jul 20, 2009 at 2:06 PM, Daniel Rice (דניאל רייס)r...@google.com wrote: Hi all - I've been working on a patch to improve support for RPC of persistence-enhanced objects that would replace the one I recently submitted as trunk revision 5672. I'd like to give those of you who are interested in the interaction between RPC and persistence a chance to help me validate the design before moving forward. The idea is to be able to deal with different persistence mechanisms in a way that does not depend too much on the details of their implementations. We assume that the persistence mechanism provides a way for instances to be detached from the object store, serialized, deserialized, and reattached in a well-defined way. Our strategy leverages this capability as follows: 1) User code on the server detaches the object and places it into a state such that serialization is valid 2) GWT detects whether any instance fields are present on the object that were not known to client code 3) GWT performs hybrid serialization: a) GWT uses its regular RPC mechanism for the client-visible fields b) GWT uses Java serialization for any additional server-only instance fields c) GWT encodes the results of step (b) as a String d) GWT prepends the encoded String to the regular RPC data and transmits to the client 4) Client code treats the object in the normal way and does not interact with the data from step (3b) 5) When the object is sent back to the server, the normal RPC mechanism is altered as follows a) the encoded server data is decoded and deserialized into the new object instance b) the client data is populated using setXXX() method invocations rather than by directly setting field values All this is done only for classes that can be send bidirectionally, and which are determined to be (potentially) enhanced. The potential for enhancement is signaled in one of three ways: o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' configuration property o The class is determined to have the JDO @PersistenceCapable annotation with detachable=true o The class is determined to have the JPA @Entity annotation If a class is determined to be potentially enhanced, the list of fields known to the client is added to the '.gwt.rpc' file that contains the RPC whitelist. This list is used by step 2 of the RPC process which compares the set of client- and server-visible fields. Step (5b) is necessary to accommodate mechanisms like that of JDO, where the setter methods are enhanced to provide object state tracking (dirty bits). If we were to set the fields directly, the object detached state would not be updated properly. My hope is that this mechanism would be general enough to support a variety of persistence mechanisms without the need to add a lot of special-case code. I'm looking forward to any comments that you have as to whether this will work with your favorite persistence API, or any other thoughts that you have. Thanks, Dan --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Issue #188 has 40 stars, making it number seven in the issue list (when sorted appropriately). Let's shoot for number one before John gets back to working on it. ;-) So if you're anxious for PST to leave the incubator, star this issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=188 - Isaac On Thu, Jul 16, 2009 at 10:58 AM, John LaBancajlaba...@google.com wrote: We probably won't decide what to move into trunk until we get closer to the next release. I'm working on improving our unit test coverage to make GWT more stable, and most of the other UI developers are busy on their own tasks. Sorry I don't have a better answer, but I'll escalate the fact that quite a few people have been asking about the table and would like to see it in trunk. Thanks, John LaBanca jlaba...@google.com On Wed, Jul 15, 2009 at 6:31 PM, jay jay.gin...@gmail.com wrote: Bump again? Any status? thanks... jay On Jul 7, 8:40 am, jay jay.gin...@gmail.com wrote: bump. Anything? On Jun 24, 10:31 am, jay jay.gin...@gmail.com wrote: Just curious if the effort has been resumed? Regardless, is there anyway for you to commit what you do have somewhere we could look and provide feedback? thanks, jay On Jun 10, 8:28 am, John LaBanca jlaba...@google.com wrote: @jay - I got side tracked with other tasks, but I'll pick up the PagingScrollTable effort within a couple of weeks. The main goal when we transfer the PagingScrollTable to GWT trunk is to separate the concept of scrolling (with three distinct tables) from the rest of the code. That way, we can bulk render a single table element that includes the header,data, and footer and have it layout naturally. @dflorey - I definitely plan to include all three of your points into the scroll table. Thanks again for all your contributions. I don't know exactly how long it will take to integrate everything into the GWT trunk, but its one of my highest priorities. Thanks, John LaBanca jlaba...@google.com On Wed, Jun 10, 2009 at 10:15 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'd like to support this effort and would be glad if some of my changes would make it into trunk: - filters - column types for most frequently used column types (numbers,dates,text) including proper filtering, editing and sorting capabilities - simplified table generation ( see http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable ) (TreeTable is not ready for prime time yet) Daniel On 10 Jun., 05:34, jay jay.gin...@gmail.com wrote: I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide. jay On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as
[gwt-contrib] Re: GWT 1.7 Now Available
I decided to jump on 1.7 this morning. Looks good so far. No compilation problems, no new issues so far, and IE8 behavior much better. Thank you, Bruce, et al. On Mon, Jul 13, 2009 at 9:01 PM, Bruce Johnsonbr...@google.com wrote: Hi everyone, GWT 1.7 is a minor update that adds better support for Internet Explorer 8, Firefox 3.5, and Safari 4. Each of these new browser versions introduced at least one change that negatively impacted compiled GWT modules, so we recommend that you do update to GWT 1.7 and recompile your existing applications to ensure that they work with the latest versions of browsers. No source code changes on your part should be required. Normally, a minor update such as this would have been named 1.6.5 (the previous latest version of GWT was 1.6.4), but we did add the value ie8 to the user.agent deferred binding property, which could impact projects using custom deferred binding rules that are sensitive to that property. Thus, we went with GWT 1.7 rather than GWT 1.6.5, to indicate that you may need to pay attention to that change. Details are in the release notes. In every other respect, this is just a bugfix release, so in the vast majority of cases, the update-recompile process should be nearly effortless. Download here: http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=GWT+1.7.0 Cheers, Bruce, on behalf of your friendly GWT Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.7 Now Available
Have you tried building incubator from trunk? I'm using more recent incubator code and it compiles for me with GWT 1.7. On Tue, Jul 14, 2009 at 4:37 PM, Fushionmenno.van.gange...@gmail.com wrote: Same problem here. On Jul 14, 4:45 pm, ma m...@coware.de wrote: Hello, I have problems with GWT1.7 and the actual release of the gwt- incubator library (gwt-incubator-march-02-2009.jar). The following compile errors occur in my project: ... [java] [ERROR] Errors in 'jar:file:../gwt-incubator- march-02-2009.jar!/com/google/gwt/widgetideas/client/GlassPanel.java' [java] [ERROR] Line 91: Rebind result 'com.google.gwt.widgetideas.client.impl.GlassPanelImpl' cannot be abstract [java] [ERROR] Errors in 'jar:file:../gwt-incubator- march-02-2009.jar!/com/google/gwt/gen2/logging/impl/client/ ClientConsoleLogHandlerImpl.java' [java] [ERROR] Line 206: Rebind result 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl' must be a class [java] [ERROR] Cannot proceed due to previous errors ... Is there a new incubator release planned where these issues are fixed? Markus --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Patch for incubator issue #271
Hi John, I know that PagingScrollTable is headed for trunk already, but I thought we could slip this small patch into the incubator for the mean time. Would you mind giving it a quick review? Thanks, Isaac Index: src/com/google/gwt/widgetideas/table/client/PagingOptions.java === --- src/com/google/gwt/widgetideas/table/client/PagingOptions.java (revision 1681) +++ src/com/google/gwt/widgetideas/table/client/PagingOptions.java (working copy) @@ -173,7 +173,7 @@ numPagesLabel = new HTML(); // Create the loading image -loadingImage = new Image(scrollTableLoading.gif); +loadingImage = new Image(GWT.getModuleBaseURL() + scrollTableLoading.gif); loadingImage.setVisible(false); // Create the error label Index: src/com/google/gwt/gen2/table/client/PagingOptions.java === --- src/com/google/gwt/gen2/table/client/PagingOptions.java (revision 1681) +++ src/com/google/gwt/gen2/table/client/PagingOptions.java (working copy) @@ -182,7 +182,7 @@ numPagesLabel = new HTML(); // Create the loading image -loadingImage = new Image(scrollTableLoading.gif); +loadingImage = new Image(GWT.getModuleBaseURL() + scrollTableLoading.gif); loadingImage.setVisible(false); // Create the error label --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch for incubator issue #271
Thanks. Committed as r1682 in incubator. On Thu, Jun 18, 2009 at 4:47 PM, John LaBanca jlaba...@google.com wrote: LGTM. I'll update this tomorrow. Thanks, John LaBanca jlaba...@google.com On Thu, Jun 18, 2009 at 4:30 PM, Isaac Truett itru...@gmail.com wrote: Hi John, I know that PagingScrollTable is headed for trunk already, but I thought we could slip this small patch into the incubator for the mean time. Would you mind giving it a quick review? Thanks, Isaac Index: src/com/google/gwt/widgetideas/table/client/PagingOptions.java === --- src/com/google/gwt/widgetideas/table/client/PagingOptions.java (revision 1681) +++ src/com/google/gwt/widgetideas/table/client/PagingOptions.java (working copy) @@ -173,7 +173,7 @@ numPagesLabel = new HTML(); // Create the loading image -loadingImage = new Image(scrollTableLoading.gif); +loadingImage = new Image(GWT.getModuleBaseURL() + scrollTableLoading.gif); loadingImage.setVisible(false); // Create the error label Index: src/com/google/gwt/gen2/table/client/PagingOptions.java === --- src/com/google/gwt/gen2/table/client/PagingOptions.java (revision 1681) +++ src/com/google/gwt/gen2/table/client/PagingOptions.java (working copy) @@ -182,7 +182,7 @@ numPagesLabel = new HTML(); // Create the loading image -loadingImage = new Image(scrollTableLoading.gif); +loadingImage = new Image(GWT.getModuleBaseURL() + scrollTableLoading.gif); loadingImage.setVisible(false); // Create the error label --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Re: Bruce's point about expectations and features vs. performance. Has there been (or should we start) discussion for the public record of different facets/features of tables, their impact on performance, and their possible class structure? What I'm thinking of specifically is bulk rendering vs. dynamic model-backed tables, scrolling, paging, and all the combinatorial permutations thereof. Will supported features be part of a single class hierarchy as they are in Incubator (i.e., PagingScrollTable extends ScrollTable; paging code is bound to scrolling code, although scrolling can be disabled it would still add code to the compiled app)? Or will they be pluggable features into a base Table class (like MonthSelectors for DatePickers)? Or separate implementations of a common Table interface? - Isaac On Wed, Jun 10, 2009 at 11:27 AM, Bruce Johnson br...@google.com wrote: I'll be the bad guy and try to lower expectations: whatever we end up doing, it has to be fast. We've seen some *horrible* usability problems with fancy tables -- even at a small number of rows -- and so don't be surprised if we have to pare back features and reduce API flexibility to ensure that a few key use cases are sufficiently high performance. -- Bruce On Tue, Jun 9, 2009 at 10:12 AM, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when it ends. * Flexibility is great, but often I'm just interested in the simple cases...simple. My example here is the multiple-row header stuff. It's GREAT! I LOVE it! (And better yet, our customers have been screaming for this!) But, I don't always need/want it. And, it can make things more complex. One idea would be to overload methods like getHeader() on AbstractColumnDefinition...add a version that doesn't take a 'row' parameter, and so just assumes there's only 1 row. * More use of generics, less casting (for me). Some examples: o AbstractColumnDefinition returns Object for the getHeader() method. Why not declare this as class AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, so that the method could be declared as public TABLE_DEFINITION getTableDefinition()? I apologize if I'm being overly simplistic or if I'm asking too much. I definitely apologize for not following up my
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) Would keeping that VM alive open up the possibility of a semi-incremental build? On Fri, Jun 5, 2009 at 1:52 PM, Scott Blum sco...@google.com wrote: On Fri, Jun 5, 2009 at 1:47 PM, Lex Spoon sp...@google.com wrote: Reading further in the thread, though, maybe we should simply use -server! Funny enough, I used to use -server in all my launch configs, but at some point I found it seemed actually a lot slower most of the time, due to all the overhead. I think you need a really big compile to make it worth it (30-perm Showcase might be worth it, the other samples probably not). Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: ant de-duplication
Could you build the jar incrementally using uptodate to update with
newer/missing files from each source directory?
On Wed, Jun 3, 2009 at 2:13 PM, Freeland Abbott fabb...@google.com wrote:
Well, I did try to use filesonly first. ;-)
Taking the worst-case example of the com/ directory entry from a
hypothetical amalgam of user/build.xml and dev/common.xml's jars, we might
have up five instances of the com/ directory being added to a jar (that
is, sources from src and super, built classes from core and platform, and
entries from tools jars---maybe lots of those, but they're all old and all
the same type, so I'll lump them together). With
duplicate=add|preserve|fail, we can make either the first or last one win,
but we want the newest one to win.
We could, instead of this tack, write our own task, perhaps extending ant's
JarTask, and do the most recent filtering there. That seemed heavier than
we needed, and the zipfilesets an irritating twist to handle, but it
certainly lets us set the control directly the way we want it, i.e. by date
instead of lexical order.
On Wed, Jun 3, 2009 at 1:41 PM, Scott Blum sco...@google.com wrote:
It begins to feel as though we're on the wrong track. :( All we're really
trying to solve is jarring things up in a particular order. But in the
process, we're defining tags like sourcefiles and artifacts that seem
imbued with meaning. All all this (really) just to solve the issue of
adding directory entries. I'm ok with proceeding down this path if there
really isn't any more straightfoward way to solve this, but I think we're at
a point where it's worth taking a second look high-level.
On Wed, Jun 3, 2009 at 1:31 PM, fabb...@google.com wrote:
http://gwt-code-reviews.appspot.com/33837/diff/10/1008
File common.ant.xml (right):
http://gwt-code-reviews.appspot.com/33837/diff/10/1008#newcode149
Line 149: element name=manifestcontents optional=true/
On 2009/06/03 05:06:18, scottb wrote:
Does it not work to just call this manifest?
Nope, or at least not that I could find. (That was my first attempt,
actually.) If the macrodef has an element named manifest, then in the
macro manifest means the contents of that user-supplied element (but
not the user-supplied element itself, sadly). And if I use an implicit
element (e.g. jarelements, such that manifest is implicitly a child
of that), I'm only allowed one element total and can't separate
sourcefiles and artifacts, which is the whole point.
What we could do, though, is to use e.g. jarelements as the macrodef
element, and have callers put the jar manifest sub-element in that.
So callers would do:
gwt.jar
artifacts.../artifacts
sourcefiles.../sourcefiles
jarelements
manifest.../manifest
/jarelements
/gwt.jar
which would allow, not just manifest, but also metainf, indexjars,
service... and fileset, which makes me nervous, but would at least
have well-defined ordering behind artifacts/ and sourcefiles/.
Would that be better?
http://gwt-code-reviews.appspot.com/33837/diff/10/1011
File dev/core/build.xml (right):
http://gwt-code-reviews.appspot.com/33837/diff/10/1011#newcode27
Line 27: sourcefiles
On 2009/06/03 05:06:18, scottb wrote:
artifacts seems to make more sense here
Somewhat arbitrary choice, yes, but we want that artifacts must be
definitively newer than sourcefiles. Since the jars here will have
dates as set by svn, and the contents as baked-in to the download files
(as opposed to dates set by ant compilation), I called them sourcefiles.
But we don't have anything that we build ourselves here, so it doesn't
in the end matter.
http://gwt-code-reviews.appspot.com/33837/diff/10/1016
File user/build.xml (right):
http://gwt-code-reviews.appspot.com/33837/diff/10/1016#newcode82
Line 82: zipfileset src=${gwt.tools.lib}/tomcat/servlet-api-2.5.jar
/
On 2009/06/03 05:06:18, scottb wrote:
Seems like this line and the next two should artifacts... does it
make a
difference, or is my intuition wildly wrong?
Your intuition is mildly wrong. The point of artifact is to hint
about what's going to have the newest touch dates, i.e. what's generated
by ant rather than touched from svn.
Given that these contain org/... classes, the practical impact is small,
but if they were com/... classes, the jars presumably would have
older-than-now dates on the com/ entry (indeed, it's May 2008 for
flute's org/ entry), so making them artifacts could cause spurious
rebuild activity to freshen the directory entries.
http://gwt-code-reviews.appspot.com/33837
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: ant de-duplication
You can do excludes with foreach:
foreach
path
fileset dir=foo
exclude name=**/*.properties /
/fileset
path
/foreach
On Wed, Jun 3, 2009 at 2:31 PM, Freeland Abbott fabb...@google.com wrote:
Potentially, yes... that would make building the jar a longer operation
(several updates, not one pass), but would ensure that the newest thing was
in place at the end of the first cycle, which is what we want.
But I think ant-contrib's foreach, operates on paths, which I think
precludes exclusion (e.g. of **/*.properties, which we do from src because
they've been filtered into bin). So we'd probably still end up writing some
custom Ant task code...
On Wed, Jun 3, 2009 at 2:21 PM, Isaac Truett itru...@gmail.com wrote:
Could you build the jar incrementally using uptodate to update with
newer/missing files from each source directory?
On Wed, Jun 3, 2009 at 2:13 PM, Freeland Abbott fabb...@google.com
wrote:
Well, I did try to use filesonly first. ;-)
Taking the worst-case example of the com/ directory entry from a
hypothetical amalgam of user/build.xml and dev/common.xml's jars, we
might
have up five instances of the com/ directory being added to a jar
(that
is, sources from src and super, built classes from core and platform,
and
entries from tools jars---maybe lots of those, but they're all old and
all
the same type, so I'll lump them together). With
duplicate=add|preserve|fail, we can make either the first or last one
win,
but we want the newest one to win.
We could, instead of this tack, write our own task, perhaps extending
ant's
JarTask, and do the most recent filtering there. That seemed heavier
than
we needed, and the zipfilesets an irritating twist to handle, but it
certainly lets us set the control directly the way we want it, i.e. by
date
instead of lexical order.
On Wed, Jun 3, 2009 at 1:41 PM, Scott Blum sco...@google.com wrote:
It begins to feel as though we're on the wrong track. :( All we're
really
trying to solve is jarring things up in a particular order. But in the
process, we're defining tags like sourcefiles and artifacts that
seem
imbued with meaning. All all this (really) just to solve the issue of
adding directory entries. I'm ok with proceeding down this path if
there
really isn't any more straightfoward way to solve this, but I think
we're at
a point where it's worth taking a second look high-level.
On Wed, Jun 3, 2009 at 1:31 PM, fabb...@google.com wrote:
http://gwt-code-reviews.appspot.com/33837/diff/10/1008
File common.ant.xml (right):
http://gwt-code-reviews.appspot.com/33837/diff/10/1008#newcode149
Line 149: element name=manifestcontents optional=true/
On 2009/06/03 05:06:18, scottb wrote:
Does it not work to just call this manifest?
Nope, or at least not that I could find. (That was my first attempt,
actually.) If the macrodef has an element named manifest, then in
the
macro manifest means the contents of that user-supplied element
(but
not the user-supplied element itself, sadly). And if I use an
implicit
element (e.g. jarelements, such that manifest is implicitly a
child
of that), I'm only allowed one element total and can't separate
sourcefiles and artifacts, which is the whole point.
What we could do, though, is to use e.g. jarelements as the macrodef
element, and have callers put the jar manifest sub-element in that.
So callers would do:
gwt.jar
artifacts.../artifacts
sourcefiles.../sourcefiles
jarelements
manifest.../manifest
/jarelements
/gwt.jar
which would allow, not just manifest, but also metainf,
indexjars,
service... and fileset, which makes me nervous, but would at least
have well-defined ordering behind artifacts/ and sourcefiles/.
Would that be better?
http://gwt-code-reviews.appspot.com/33837/diff/10/1011
File dev/core/build.xml (right):
http://gwt-code-reviews.appspot.com/33837/diff/10/1011#newcode27
Line 27: sourcefiles
On 2009/06/03 05:06:18, scottb wrote:
artifacts seems to make more sense here
Somewhat arbitrary choice, yes, but we want that artifacts must be
definitively newer than sourcefiles. Since the jars here will have
dates as set by svn, and the contents as baked-in to the download
files
(as opposed to dates set by ant compilation), I called them
sourcefiles.
But we don't have anything that we build ourselves here, so it doesn't
in the end matter.
http://gwt-code-reviews.appspot.com/33837/diff/10/1016
File user/build.xml (right):
http://gwt-code-reviews.appspot.com/33837/diff/10/1016#newcode82
Line 82: zipfileset src=${gwt.tools.lib}/tomcat/servlet-api-2.5.jar
/
On 2009/06/03 05:06:18, scottb wrote:
Seems like this line and the next two should artifacts... does it
make a
difference, or is my intuition wildly wrong?
Your intuition is mildly wrong
[gwt-contrib] Re: possible ant changes
+1 for Fred's use case. And bonus points if I can specify an SVN revision at the command line and have it check out that revision and build it in one step. ... on second thought, that might be more appropriate for a tool separate from the build script, but I'll throw it out there anyway. - Isaac On Wed, May 27, 2009 at 2:51 PM, Fred Sauer fre...@google.com wrote: I have not. I've gone treasure hunting a couple of times, but did not find a good build target. I'll give buildonly a try. (On my system (Vista :) creating the zips for the ditros actually takes some time. Building the jars for the two platforms I don't need (at that moment at least) also takes time that would be nice to avoid. Anyway, I'll try buildonly. Thanks Fred On Wed, May 27, 2009 at 11:46 AM, Freeland Abbott fabb...@google.com wrote: I think that's about what I'm hoping to make ant build become. In terms of what's there today, Fred, have you tried the existing top-level buildonly target? My complaint with that one is that it doesn't get the .so/.dll files into a usable place, but if you manually drop them into build/lib, I think it's the closest we have today. On Wed, May 27, 2009 at 2:34 PM, Fred Sauer f...@allen-sauer.com wrote: My pain point: I often want a trunk build of GWT to quickly test a patch. In this case I only need the GWT build for the current platform whatever that is. I don't need samples/demos nor do I need/want tests. I don't need a zipped up distro, just the jars. Even javadocs would be optional. Of course I want all of that and be able to do incremental builds. I imagine something like this: 1. ant clean platform-jars 2. (make a small code change to GWT compiler and/or GWT widgets) 3. ant platform-jars (fast, incremental build) Fred On Wed, May 27, 2009 at 10:38 AM, Freeland Abbott fabb...@google.com wrote: So, I'm looking at our ant files, and trying to unwind several problems... but I figure I'll ask what other people have as pet peeves, to see if there are other games I should play, too. Here's what's on my mind right now: If you run ant clean build; ant build, the second build should be zero work. It's not, and in particular it painfully builds samples twice. It shouldn't. Right now, tests require a staging directory, which implies requiring a full distro kit including samples. That's unnecessary; tests should require build, but not much more. Related to that, too much depends on the semi-recursive -do, which is actually a no-op that depends on dist, which pulls too much in for simple cases. Largely orthogonal, we have checked in files with $ in their names, which are supposed to also be usable wtih _ instead. I've got a system which is badly allergic to the $'s, which is why this causes me pain, but generally it seems this should be addressed with alternate classpath roots anyway, so we can test both the two cases easily. Does anyone have other pain points to add? What I was thinking of doing is: Shoot the top-level -do target, in favor of having subtargets directly invoke what they need from subprojects, via antcall, and setting target as is done today... so e.g. target test can depend target build or buildonly and then antcall the test targets of dev, user, etc. explicitly. Since -do would no longer exist, it wouldn't depend on dist to get the fan-out effects, and fan-out can be more selectively controlled. Untangle whatever our double-build is caused by; at first blush, it seems to think my directories are out of date relative to the existing jar (not the files in them, but the directories themselves). Change the default target to dist, for back compatibility, since that's what build today really does (build depends on -do which depends on dist which depends on build in all the subprojects). Twiddle the semantics of build to be just building. I haven't decided whether that would include building samples (probably; buildonly exists to skip that), but it wouldn't assemble the distro archive and then unpack it as dist does. Introduce user/test_dollar and user/test_underbar as java-root directories with the obvious subset of files from today's user/test, and an adjustment to the test target one or the other is on classpath, controlled I think by a system property. Thoughts on that? -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: possible ant changes
I have done something similar in the past. I wrote an Ant target to update from CVS, build, and deploy an app. It *usually* worked all in one space, which was good enough at the time. If you want to check out revision x and then have revision x of build.xml run the actual build, you could exec the new version. On Wed, May 27, 2009 at 3:10 PM, Freeland Abbott fabb...@google.com wrote: Separate tool. If the ant files that you start with are different than the ones at the revision you're asking for, do you really want the ant launched in the first revision-space to be driving? On Wed, May 27, 2009 at 2:59 PM, Isaac Truett itru...@gmail.com wrote: +1 for Fred's use case. And bonus points if I can specify an SVN revision at the command line and have it check out that revision and build it in one step. ... on second thought, that might be more appropriate for a tool separate from the build script, but I'll throw it out there anyway. - Isaac On Wed, May 27, 2009 at 2:51 PM, Fred Sauer fre...@google.com wrote: I have not. I've gone treasure hunting a couple of times, but did not find a good build target. I'll give buildonly a try. (On my system (Vista :) creating the zips for the ditros actually takes some time. Building the jars for the two platforms I don't need (at that moment at least) also takes time that would be nice to avoid. Anyway, I'll try buildonly. Thanks Fred On Wed, May 27, 2009 at 11:46 AM, Freeland Abbott fabb...@google.com wrote: I think that's about what I'm hoping to make ant build become. In terms of what's there today, Fred, have you tried the existing top-level buildonly target? My complaint with that one is that it doesn't get the .so/.dll files into a usable place, but if you manually drop them into build/lib, I think it's the closest we have today. On Wed, May 27, 2009 at 2:34 PM, Fred Sauer f...@allen-sauer.com wrote: My pain point: I often want a trunk build of GWT to quickly test a patch. In this case I only need the GWT build for the current platform whatever that is. I don't need samples/demos nor do I need/want tests. I don't need a zipped up distro, just the jars. Even javadocs would be optional. Of course I want all of that and be able to do incremental builds. I imagine something like this: 1. ant clean platform-jars 2. (make a small code change to GWT compiler and/or GWT widgets) 3. ant platform-jars (fast, incremental build) Fred On Wed, May 27, 2009 at 10:38 AM, Freeland Abbott fabb...@google.com wrote: So, I'm looking at our ant files, and trying to unwind several problems... but I figure I'll ask what other people have as pet peeves, to see if there are other games I should play, too. Here's what's on my mind right now: If you run ant clean build; ant build, the second build should be zero work. It's not, and in particular it painfully builds samples twice. It shouldn't. Right now, tests require a staging directory, which implies requiring a full distro kit including samples. That's unnecessary; tests should require build, but not much more. Related to that, too much depends on the semi-recursive -do, which is actually a no-op that depends on dist, which pulls too much in for simple cases. Largely orthogonal, we have checked in files with $ in their names, which are supposed to also be usable wtih _ instead. I've got a system which is badly allergic to the $'s, which is why this causes me pain, but generally it seems this should be addressed with alternate classpath roots anyway, so we can test both the two cases easily. Does anyone have other pain points to add? What I was thinking of doing is: Shoot the top-level -do target, in favor of having subtargets directly invoke what they need from subprojects, via antcall, and setting target as is done today... so e.g. target test can depend target build or buildonly and then antcall the test targets of dev, user, etc. explicitly. Since -do would no longer exist, it wouldn't depend on dist to get the fan-out effects, and fan-out can be more selectively controlled. Untangle whatever our double-build is caused by; at first blush, it seems to think my directories are out of date relative to the existing jar (not the files in them, but the directories themselves). Change the default target to dist, for back compatibility, since that's what build today really does (build depends on -do which depends on dist which depends on build in all the subprojects). Twiddle the semantics of build to be just building. I haven't decided whether that would include building samples (probably; buildonly exists to skip that), but it wouldn't assemble the distro archive and then unpack it as dist does. Introduce user/test_dollar and user/test_underbar as java-root directories with the obvious subset
[gwt-contrib] Re: gen2 PagingScrollTable column widths
Jay,
Am I right in understanding that you're expecting the table, when
unconstrained, to grow until each column can occupy its preferred
width? It should be possible to achieve that, although just setting
preferred size may not be enough. There used to be a setColumnWidth()
method that would set a column's size, but still allow it to be
resized later. I don't know what the gen2 PST equivalent would be, but
I can dig around a bit later if I get some time.
On Mon, May 11, 2009 at 1:14 PM, jay jay.gin...@gmail.com wrote:
But if I set the min and max sizes, then the user cannot resize the
columns. And...well, my users need to be able to resize the columns...
So, I guess I should enter a feature request (or else provide a
patch ;-) that there some way for the table to set the initial column
width to the preferred width.
jay
On May 7, 6:08 pm, John LaBanca jlaba...@google.com wrote:
If you want the columns to be an exact size, set the minimum and maximum
column widths and call resetColumnWidths() or set the resize policy to
FIXED.
The preferred width is exactly that, the width that the columns should
attempt to maintain if they can. When the resize policy is set to
FILL_WIDTH, the table will update the column widths on every page load.
When it is set to anything else, you must update the width manually
(although that is probably a bug). Either way, the preferred width is not
guaranteed, but the minimum and maximum widths are.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, May 7, 2009 at 7:11 PM, jay jay.gin...@gmail.com wrote:
I've set my table resize policy to UNCONSTRAINED. I then very
carefully setup my ColumnDefinitions to have the right preferred size
(because the user may have previously resized the columns, and I need
to honor that size).
What I've noticed, though, is that out-of-the-box, my columns are
*always* 80px wide (which seems to correspond to
FixedWidthGrid.DEFAULT_COLUMN_WIDTH.
It seems to me (and please...correct me if I'm misusing/abusing the
PagingScrollTable) that when I set the table definition, it should be
setting the column widths to their preferred size, rather than
allowing the default size to kick in.
FWIW, my work-around is to override setTableDefinition() as follows:
�...@override
public void setTableDefinition(
TableDefinitionRowType tableDefinition
) {
super.setTableDefinition( tableDefinition );
refreshVisibleColumnDefinitions();
ListColumnDefinitionRowType, ? columns =
getVisibleColumnDefinitions();
for ( int index = 0, numCols = columns.size(); index numCols;
index++ ) {
setColumnWidth( index, columns.get
( index ).getPreferredColumnWidth() );
}
}
Would problems be caused if this behavior was in the base class? (My
goal is to have the PagingScrollTable just work. I'll be the first
to admit that what I consider just working may not work for
others...)
thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 PagingScrollTable column widths
Yep, that is what you're doing. Sorry for my failure at reading
comprehension. :)
I can certainly see why you would have that expectation for an
unconstrained table. And if I'm reading John's probably a bug
comment correctly, then it sounds like that might be a good thing to
enter in the issue tracker.
And your comments are certainly welcome. Feedback is always needed,
especially in the incubator.
On Mon, May 11, 2009 at 4:11 PM, jay jay.gin...@gmail.com wrote:
Yes! When the table width is unconstrained, I want it to honor the
preferred width of every column.
If you glance back at my original post, you'll see that I'm doing
exactly what you suggest :-) It's just that this was surprising to me,
and required more work than I think ought to be needed.
(I understand that this widget is still in the incubator... I hope
that my comments are coming across as helpful, because I really am
trying to be helpful, and not critical. I chalk all of this up to
hey...let's throw something out there, and see what else needs to be
done.)
thanks!
jay
On May 11, 11:31 am, Isaac Truett itru...@gmail.com wrote:
Jay,
Am I right in understanding that you're expecting the table, when
unconstrained, to grow until each column can occupy its preferred
width? It should be possible to achieve that, although just setting
preferred size may not be enough. There used to be a setColumnWidth()
method that would set a column's size, but still allow it to be
resized later. I don't know what the gen2 PST equivalent would be, but
I can dig around a bit later if I get some time.
On Mon, May 11, 2009 at 1:14 PM, jay jay.gin...@gmail.com wrote:
But if I set the min and max sizes, then the user cannot resize the
columns. And...well, my users need to be able to resize the columns...
So, I guess I should enter a feature request (or else provide a
patch ;-) that there some way for the table to set the initial column
width to the preferred width.
jay
On May 7, 6:08 pm, John LaBanca jlaba...@google.com wrote:
If you want the columns to be an exact size, set the minimum and maximum
column widths and call resetColumnWidths() or set the resize policy to
FIXED.
The preferred width is exactly that, the width that the columns should
attempt to maintain if they can. When the resize policy is set to
FILL_WIDTH, the table will update the column widths on every page load.
When it is set to anything else, you must update the width manually
(although that is probably a bug). Either way, the preferred width is not
guaranteed, but the minimum and maximum widths are.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, May 7, 2009 at 7:11 PM, jay jay.gin...@gmail.com wrote:
I've set my table resize policy to UNCONSTRAINED. I then very
carefully setup my ColumnDefinitions to have the right preferred size
(because the user may have previously resized the columns, and I need
to honor that size).
What I've noticed, though, is that out-of-the-box, my columns are
*always* 80px wide (which seems to correspond to
FixedWidthGrid.DEFAULT_COLUMN_WIDTH.
It seems to me (and please...correct me if I'm misusing/abusing the
PagingScrollTable) that when I set the table definition, it should be
setting the column widths to their preferred size, rather than
allowing the default size to kick in.
FWIW, my work-around is to override setTableDefinition() as follows:
�...@override
public void setTableDefinition(
TableDefinitionRowType tableDefinition
) {
super.setTableDefinition( tableDefinition );
refreshVisibleColumnDefinitions();
ListColumnDefinitionRowType, ? columns =
getVisibleColumnDefinitions();
for ( int index = 0, numCols = columns.size(); index numCols;
index++ ) {
setColumnWidth( index, columns.get
( index ).getPreferredColumnWidth() );
}
}
Would problems be caused if this behavior was in the base class? (My
goal is to have the PagingScrollTable just work. I'll be the first
to admit that what I consider just working may not work for
others...)
thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 PagingScrollTable scroll indicator
Hi Jay, That does sound like a bug. Opening an issue in the tracker is a good idea. Issues with patches attached are even better. - Isaac On Thu, May 7, 2009 at 3:02 PM, jay jay.gin...@gmail.com wrote: I'm starting to use the gen2 incubator table widgets. I hope I can provide some valuable feedback in the days and weeks to come... The first issue I've run into that I cannot seem to work around: When I load my data into the PagingScrollTable, it is already sorted (in fact, all of our data uses server-side sorting). I worked out that in order to get the sorting indicator displayed, I should call: ColumnSortList sortList = ...; getDataTable().setColumnSortList( sortList, true ); I can see that this fires the event which PagingScrollTable listens for. However, when PagingScrollTable gets the event, it checks to see if the sortedColumnTrigger member is null. In this case, it is, because the only way for that (private) member to be set is in reaction to a ONMOUSEUP event. What's the best way to resolve this? Should I file a bug? Submit a patch? Something else? thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT-Incubator: GlassPanel changes
I'm with Joel on keeping the native ListBox. There's no reason that it can't co-exist with other implementations, such as the incubator's DropDownListBox. On Tue, May 5, 2009 at 9:13 AM, Joel Webber j...@google.com wrote: I'll admit to not having used the incubator GlassPanel in a while, but its setFocus() behavior does sound like something that should be optional, for precisely the reasons you describe. I do want to point out that it would be pretty unreasonable to actually deprecate the native ListBox/select element. It's a normal part of HTML forms, and our goal is most definitely not to make everything work as long as you only use the controls and elements we bless. On Tue, May 5, 2009 at 8:24 AM, David david.no...@gmail.com wrote: Hi, I just created a trimmed down GlassPanel that only contains what we need. Just as a thought on bug 1186, why not deprecate the ListBox widget and replace it with a custom widget. The standard listbox in the browser is underpowered when it comes to styling. I would like to put more than just strings in there. If that were the case then all these tricks to get dialogs to render correctly while dragging or to cancel events are no longer needed in IE6. David On Tue, May 5, 2009 at 12:49 PM, Thomas Broyer t.bro...@gmail.com wrote: On 5 mai, 10:15, stuckagain david.no...@gmail.com wrote: Hi, We are currently moving to the GWT 1.6 release and also updated to the latest incubator. I am having a problem with the GlassPanel widget in the incubator and looked a bit into the implementation. It has a functionality that it automatically grabs the focus. This functionality is not what we wanted so in a previous version if had just overriden the setFocus method to override this behaviour. We are using the GlassPanel to only block part of our UI when input fields are changed by the user. The side effect is that now when the user changes the input field, after one character, the GlassPanel is shown and the user has to click on the input field again to continue entering data. Could this automatically grabbing the focus be made optional ? Right now I can only see a solution by copying the code and deleting this unwanted functionality since the rework of the component no longer allows me to change the behaviour. the GlassPanel should be usable in more situations than just to block the complete window. I agree, and even in those situations, when used in combination with a modal popup panel, grabbing the focus isn't strictly necessary either (note that PopupPanel does not grab the focus, instead it eats up every event not targeted at the modal popup panel). I do believe actually that the lightbox effect should be done by the popup panel (when modal), as it would also solve issue 1186 [1] (defaulting to being fully transparent) [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=1186 I also see in the code that in onAttach a FocusPanelImpl is attached to the root panel... does this mean that every time I remove the GlassPanel from the page and reattach that it will add another FocusPanelImpl ? That looks like a leak to me (the onDetach does not remove it unless I overlooked it ?) As said on the JavaDoc for this FocusPanelImpl class, it removes itself (it does this as soon as it gains the focus, which it grabs as soon as it's attached to the document). Another comment is the usage of a WindowResizeListener. Isn't this duplicate code from the ResizableWidgetCollection ? GlassPanel has unfortunately not been updated for a while (including for GWT 1.6: uses WindowResizeListener instead of ResizeHandler, EventPreview instead of NativePreviewHandler, etc.). Maybe it's time to rewrite it, and/or split it into more a set of widgets, each one specialized on one thing (lightbox+dialog, cover part of the page, etc.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Incubator Questions
Hi Jay, Responses inline. On Tue, Apr 28, 2009 at 12:48 PM, jay jay.gin...@gmail.com wrote: I'm curious as to how it is decided a new drop of incubator should be made available? Is it based on a new GWT drop? Or maybe, there is no real release cycle? Basically in parallel with the GWT releases. The Incubator trunk tries to be compatible with GWT trunk and the latest GWT release. How about testing? Is there any official testing on the incubator widgets? Is it just the unit tests, plus whatever bug reports that may come in? There are unit tests, the demos, and anyone using Incubator trunk in development. I couldn't tell you how many developers are in that group, but it's at least one. Being an incubator, I'd expect breaking changes to roll through periodically. Is there usually a hey...we're going to break this tomorrow email that comes through the list before these things happen? Major changes usually have a design document on the wiki and discussion thread on this group. Finally, I've not seen any good description of how it is decided when an incubator widget graduates. I guess, more particularly, what is holding back the current set of table widgets from graduating into the trunk? There aren't specific criteria that I've seen, either. I suspect (and this is purely speculation on my part - clarifications or contradictions welcome!) that promotion is largely driven by the needs of internal Google projects. If that's true, then those widgets are probably some of the most thoroughly tested, critiqued, and generally banged-upon in the Incubator. So that's a good thing. Re: table - the gen2 PagingScrollTable went through a fairly major redesign recently. I haven't seen any discussion of pending graduation. I imagine it needs time to settle after the shake up. Thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Google Plugin for Eclipse
http://code.google.com/eclipse/docs/faq.html#source It is not (yet). Although I've wondered why there isn't an empty shell of a project on Google Code, just for the Issue Tracker if nothing else. On Fri, Apr 17, 2009 at 8:20 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: Is the Google Eclipse Plugin not a Google Code OSS project? -- Arthur Kalmenson On Thu, Apr 16, 2009 at 11:18 PM, Alex Rudnick a...@google.com wrote: Gary, Here is fine (alternatively, on the Google-Web-Toolkit group). What issues and questions have you got? On Thu, Apr 16, 2009 at 8:20 PM, Gary Miller miller.ga...@gmail.com wrote: Where is the correct place to post issues and questions for Google Plugin for Eclipse? -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Comments on builder pattern?
Personally I don't care for this style of coding. I think it's very convenient for writing, but it hurts readability. On Thu, Apr 16, 2009 at 2:03 PM, Eric Ayers zun...@google.com wrote: Recently I've been wrapping some of my JavaScriptObjects using the builder pattern where an instance of the object you are setting is in the return value. http://galgwt-reviews.appspot.com/21604/diff/1/18?context=10 Which you would invoke as: DraggableObject obj = new DraggableObject(elem, DraggableObjectOptions.newInstance().setLeft(10).setTop(5)); Can anyone think of a reason I might be shooting myself in the foot performance wise or code size wise as opposed to making these strict setter methods? I don't want to set a bad example. -Eric. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Clearing up the Issue Tracker
http://code.google.com/p/google-web-toolkit/issues/list?can=2q=-Milestone:1_6_RCcolspec=ID+Type+Status+Priority+Milestone+Owner+Summarycells=tiles That should help. On Tue, Apr 14, 2009 at 3:08 PM, Luminari luminari...@gmail.com wrote: I just wanted to make a request to clear up the Issue Tracker. It's still littered with 1.6RC issues, which makes it harder to see what's open. Thanks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Announcing GWT 1.6...and quite a bit more
My hearty congratulations, and thanks, to all involved in this effort. You made my day before breakfast. On Tue, Apr 7, 2009 at 11:54 PM, Bruce Johnson br...@google.com wrote: Hi Folks! Exciting news today. Rather than attempting to describe everything here, let me point you to some blog posts that hopefully you will find interesting: GWT 1.6 and friends: http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-friends.html Seriously this time, the new language on App Engine: Java http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html Google Plugin for Eclipse -- Peanut Butter to Eclipse's Chocolate http://googlewebtoolkit.blogspot.com/2009/04/google-plugin-for-eclipse-peanut-butter.html -- Bruce, on behalf of the GWT, App Engine, and Google Plugin teams --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
I'd vote for a consistent message supplied by the compiler/hosted mode and freeform text provided by the module developer. I think that works fine for JavaDoc @deprecated. URLs and the names of successor modules can be included in the freeform text when appropriate. Unless you're planning to plug those things into a template somewhere, why do you need to separate them from the block of text? Example deprecated module: module ... deprecatedWARNING: Use of this module may result in permanent loss of productivity. Whatever you were doing with it before was wrong, so just stop already!/deprecated /module Example error message: Module foo inherits deprecated module bar. WARNING: Use of this module may result in permanent loss of productivity. Whatever you were doing with it before was wrong, so just stop already! In this contrived example, there's no URL or replacement to suggest. There isn't much information available except for the freeform text. On Mon, Apr 6, 2009 at 4:53 PM, Bruce Johnson br...@google.com wrote: On Mon, Apr 6, 2009 at 4:51 PM, John Tamplin j...@google.com wrote: On Mon, Apr 6, 2009 at 4:47 PM, Bruce Johnson br...@google.com wrote: (BTW, I could be wrong about the whole let's not have freeform text. It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? I think there may be some case where you want/need more explanation, especially if it is of the form If you were doing X, use module A -- if you were doing Y, use module B. However, I think the URL will address most of that and it is easy enough to extend it later for free-form text if it becomes useful to do so -- it is harder to remove it if we add it now but it isn't useful. The one question I have is where will the URL point for an unreleased version? Ie, say we deprecate something in trunk, where would we make the URL point for more information? The compiler does this already by including reference to HTML files that are included in the distro. It is important that this could work (i.e. file URLs). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
Oh, and... as much as I hate to suggest it, we will probably need some way to suppress the deprecation warning. Maybe: inherits name=example.module.Foo ignore-deprecation=true / Where ignore-deprecation is optional and defaults to false. I'm tempted to say that ignore-deprecation=true on a non-deprecated module produces a warning, just to discourage premature ignoring. On Tue, Apr 7, 2009 at 9:15 AM, Joel Webber j...@google.com wrote: I have to say I'm with Isaac on this one. I think it's best to keep things as simple as possible, and to keep the documentation in one place wherever possible. There's nothing stopping anyone from putting URLs in the explanatory text if they want, but I wouldn't want to have to do that in the default case. I also prefer to *not* create an overly-structured way to express deprecation, when it's nigh-impossible to think of all the possible ways people may want to deprecate things. That said, I don't think it's unreasonable to accept a simple list of superceded-by modules. On Tue, Apr 7, 2009 at 8:37 AM, Isaac Truett itru...@gmail.com wrote: I'd vote for a consistent message supplied by the compiler/hosted mode and freeform text provided by the module developer. I think that works fine for JavaDoc @deprecated. URLs and the names of successor modules can be included in the freeform text when appropriate. Unless you're planning to plug those things into a template somewhere, why do you need to separate them from the block of text? Example deprecated module: module ... deprecatedWARNING: Use of this module may result in permanent loss of productivity. Whatever you were doing with it before was wrong, so just stop already!/deprecated /module Example error message: Module foo inherits deprecated module bar. WARNING: Use of this module may result in permanent loss of productivity. Whatever you were doing with it before was wrong, so just stop already! In this contrived example, there's no URL or replacement to suggest. There isn't much information available except for the freeform text. On Mon, Apr 6, 2009 at 4:53 PM, Bruce Johnson br...@google.com wrote: On Mon, Apr 6, 2009 at 4:51 PM, John Tamplin j...@google.com wrote: On Mon, Apr 6, 2009 at 4:47 PM, Bruce Johnson br...@google.com wrote: (BTW, I could be wrong about the whole let's not have freeform text. It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? I think there may be some case where you want/need more explanation, especially if it is of the form If you were doing X, use module A -- if you were doing Y, use module B. However, I think the URL will address most of that and it is easy enough to extend it later for free-form text if it becomes useful to do so -- it is harder to remove it if we add it now but it isn't useful. The one question I have is where will the URL point for an unreleased version? Ie, say we deprecate something in trunk, where would we make the URL point for more information? The compiler does this already by including reference to HTML files that are included in the distro. It is important that this could work (i.e. file URLs). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Compiling demos in incubator
Uwe,
If you change build.xml line 435 to use ${demo.src.dir} instead of
src-demo then you can specify any demo to build using command line
parameters:
-Ddemo.src.dir=src
-Ddemo.filter=**/GlassPanelDemo.gwt.xml
Note that many of the src/com/google/gwt/demos modules are obsolete
and at least one (CurrencyWidgetDemo) no longer compiles.
- Isaac
On Fri, Feb 27, 2009 at 8:35 AM, Uwe Maurer uwe.mau...@google.com wrote:
Hi,
I am trying to compile the demos which are included in incubator. I
tried
ant build.demos
but this only builds the demos which are in src-demo/, not the ones in
src/com/google/gwt/demos
How can I compile them ?
Thanks,
Uwe
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Associating Data Transfer Objects (DTOs) with Suggestion Objects
I opened issue #3409 for the Suggestion change and issue #3410 for the HasValue change. http://code.google.com/p/google-web-toolkit/issues/detail?id=3409 http://code.google.com/p/google-web-toolkit/issues/detail?id=3410 - Isaac On Wed, Feb 25, 2009 at 9:07 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: On a side note, I found when I was writing this patch that HasValue extends HasValueChangeHandlers in trunk. It occurs to me that this relationship could possibly be backwards. I don't think that something with a value necessarily should be required to broadcast changes. See the implementation of MultiWordSuggestion for an illustration of this. Requiring something that HasValueChangeHandlers to have a value (that value which changes) makes more sense to me on the face of it. This makes more sense to me too. p.s. Thank you, Gmail Labs, for reminding me that I forgot to attach the patch. Handy, ain't it? :) -- Arthur Kalmenson On Tue, Feb 24, 2009 at 6:42 PM, Isaac Truett itru...@gmail.com wrote: I basically agree with John and Ray. In general, I agree that using the most remote parent type possible (without introducing casts) is ideal. But when the subtype exists specifically as a convenience, using the parameterized super class instead and then complaining about it is... let's call it silly. To better illustrate my proposal, I have attached a quick-and-dirty patch against trunk r4850. In this patch Suggestion extends HasValue and TypedSuggestBox is a super class of SuggestBox, as I described above. On a side note, I found when I was writing this patch that HasValue extends HasValueChangeHandlers in trunk. It occurs to me that this relationship could possibly be backwards. I don't think that something with a value necessarily should be required to broadcast changes. See the implementation of MultiWordSuggestion for an illustration of this. Requiring something that HasValueChangeHandlers to have a value (that value which changes) makes more sense to me on the face of it. - Isaac p.s. Thank you, Gmail Labs, for reminding me that I forgot to attach the patch. On Tue, Feb 24, 2009 at 1:03 PM, Emily Crutcher e...@google.com wrote: 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.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
[gwt-contrib] Re: Associating Data Transfer Objects (DTOs) with Suggestion Objects
I like the super class. I'm not sure it actually needs to be abstract. I think that by adding HasValueT to Suggestion we can do it with concrete classes. TypedSuggestBoxT (SuggestBoxBase?) SuggestionT implements HasValueT SuggestOracleT SuggestBox extends TypedSuggestBoxString MultiWordSuggestOracle extends SuggestOracleString That should cover my use case and, I think, minimize impact on anyone using only the plain String suggestions. 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Associating Data Transfer Objects (DTOs) with Suggestion Objects
HasValueT extends Suggestion sounds wrong to me. I agree. SuggestBox implements HasValueT extends Suggestion was not actually what I was proposing, and I apologize if it appeared that way. T would be the type of the DAO, the logical value represented by the suggestion. My intent is that the Suggestion has a value of type T and in the common case, T is String. I'm not sure if I would go so far as to say that SuggestBox itself HasValueT, but would endorse SuggestBoxT, where T is transitive between the relevant widget, suggestion, oracle, and selection event classes, and preserves the type-safety. On Tue, Feb 24, 2009 at 10:56 AM, Ray Ryan rj...@google.com wrote: HasValueT extends Suggestion sounds wrong to me. The suggestions are not the value that we're getting from the user, they're prompts to the user to help her get to the actual value. I'd much more expect a SuggestionBox to be HasValueString -- it's just a TextBox that happens to have chats with the server. rjrjr On Tue, Feb 24, 2009 at 7:24 AM, Isaac Truett itru...@gmail.com wrote: I like the super class. I'm not sure it actually needs to be abstract. I think that by adding HasValueT to Suggestion we can do it with concrete classes. TypedSuggestBoxT (SuggestBoxBase?) SuggestionT implements HasValueT SuggestOracleT SuggestBox extends TypedSuggestBoxString MultiWordSuggestOracle extends SuggestOracleString That should cover my use case and, I think, minimize impact on anyone using only the plain String suggestions. 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Associating Data Transfer Objects (DTOs) with Suggestion Objects
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). Any thoughts on this? Horrible side effects that I'm missing? - Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.5.3: Type mismatch with enum in parameterized class.
And if I'd been silly enough to bet against you, Scott, then I
would've lost. For posterity:
1. SVN r4361 contains the updated JDT. I copied that to my 1.5 release branch.
2. SVN r4362 contains a small code change to LongFromJSNIChecker.java.
I applied that to my 1.5 branch.
3. SVN r4362 also contains the change to dev/core/build.xml to use the
new jar. Applied that.
4. Build and enjoy.
Thank you very much, Scott. This duct tape should hold until I can
upgrade to 1.6.
@Bruce - I'm eagerly waiting the turning of that corner!
Love the toolkit. Love the fast, friendly, free support. Thank you all!
- Isaac
On Wed, Jan 21, 2009 at 6:55 PM, Scott Blum sco...@google.com wrote:
Isaac, I would put money on our updating to a newer version of JDT. I'd
find where Lex committed this upgrade... if there are no code changes, you
might try putting the newer JDT higher on the classpath as a test. If that
works, simple jar surgery should get you where you want to go.
On Wed, Jan 21, 2009 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I've found an interesting error in GWT 1.5.3:
[ERROR] Line 14: Type mismatch: cannot convert from
Test.Parametric.Number
s to Test.ParametricT.Numbers
[ERROR] Line 17: Type mismatch: cannot convert from
Test.Parametric.Number
s to Test.ParametricT.Numbers
Compiling module test.Test
Computing all possible rebind results for 'test.client.Test'
Rebinding test.client.Test
Checking rule generate-with
class='com.google.gwt.user.rebind.ui.ImageBun
dleGenerator'/
[ERROR] Unable to find type 'test.client.Test'
[ERROR] Hint: Previous compiler errors may have made this type
unava
ilable
[ERROR] Hint: Check the inheritance chain from your module; it
may n
ot be inheriting a required module or a module may not be adding its
source path
entries properly
To reproduce:
public class Test implements EntryPoint {
static class ParametricT {
enum Numbers {
ONE, TWO;
}
}
public void onModuleLoad() {
switch (Parametric.Numbers.valueOf(ONE)) {
case ONE: // Line 14
System.out.println(ONE);
break;
case TWO: // Line 17
System.out.println(ONE);
break;
}
}
}
Removing the parameter from the type enclosing the enum fixes the problem.
The above *works* in trunk and 1.6, but I searched a little bit and I
couldn't find anything in the issue tracker that appeared related.
Upgrading to 1.6/trunk isn't a good option for me at the moment, so
I'm hoping that someone has seen this before and could help me find
the change that fixed it. If it's a simple patch, I can apply it to
1.5.3 until such time as an upgrade is possible. Moving the enum to a
non-parameterized type would probably work as well, but I'm loathe to
do too much redesign on account of a compiler bug that appears to
already have been fixed.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Question about Log.info,etc. methods
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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Question about Log.info,etc. methods
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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: How to deprecate non-Java files?
I was thinking along similar lines, but at compile time: 1. Include a list of deprecated public files in the release (we'll call it public-deprecated.txt). 2. Compiler gives a warning if anything from public-deprecated.txt is included in the compiled output. 3. Option to disable the warning (-noWarnPublicDeprecated). 4. Maybe an option to have the compiler specifically exclude any deprecated files from the compiled output (-excludePublicDeprecated)? On Fri, Jan 16, 2009 at 12:15 PM, Ian Petersen ispet...@gmail.com wrote: Would it be possible to engineer something that would throw up a warning message in the hosted mode logger when the client requests one of the deprecated files? Doing so probably wouldn't catch everybody because -noserver users would presumably circumvent the check, but it would probably catch a good chunk of the userbase. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: 1.6 date picker question
Thank you for the reminder, Emily! I'll get you a patch as soon as I have a few minutes to spare. On Thu, Jan 8, 2009 at 2:44 PM, Emily Crutcher e...@google.com wrote: 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] Incubator review request: DropDownDatePicker
Emily, Here's my DropDownDatePicker candidate for incubator. A few issues that I am aware of: 1. Use of deprecated API. This is coming from CustomListBox and will be resolved as things move over to the 1.6 events. 2. The size of the popup. It's too big in IE, too small in Chrome, and in Firefox, it's just right. Cue the bears. 3. I had a three, but I forgot one. Please review at your convenience. Thanks, Isaac --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- DropDownDatePicker.patch Description: Binary data
[gwt-contrib] Re: @SingleImpl versus @SingleJsoImpl
+1 for option #2. An interface that can only ever be implemented once
seems very limited in usefulness.
On Wed, Jan 7, 2009 at 10:30 AM, BobV b...@google.com wrote:
I've working on a branch that allows JavaScriptObjects to implement
interfaces with methods. Due to the lack of polymorphic dispatch of
JSOs, for a given method-bearing interface, there can be exactly one
JSO type implementing the interface. The question at hand is whether
or not to allow N-many regular Java types to also implement that
interface.
The choices are:
ONE
@SingleImpl
interface Person {
String getName();
}
class JsoPerson extends JavaScriptObject implements Person { ... }
// It is an error to define any other type that implements Person,
including anonymous types
// subclassing JsoPerson is OK
TWO
@SingleJsoImpl
interface Person {
String getName();
}
class JsoPerson extends JavaScriptObject implements Person { ... }
// It is an error to define any other JSO type that implements Person
// subclassing JsoPerson is OK
class RegularPerson implements Person { ... }
(new Person() { ... })
// But you can have as many non-JSO types implementing Person
Tradeoffs:
- Scenario one is more restrictive, but calling ((Person)
x).getName() can always be statically resolved to one method
- Land-mines with anonymous types
- Scenario two allows a JSO implementation to inter-operate with regular code
- Only land-mine would be in declaring a second JSO type
- ((Person) x).getName() would be more expensive to dispatch if
type-tightening doesn't occur; modulo optimizations, it would look
like x.typeId$ ? x.getName() : getName$(x)
- This dispatch penalty applies only to interfaces with a JSO
implementation and one or more regular implementations and
type-tightening occurs.
- Would be doing polymorphic dispatch anyway, this just adds a
ternary expression
I'm favoring scenario two because it provides the developer
significant additional flexibility. Consider the following where you
get a payload from the server in JSON format, but also want to edit
some of the resulting objects.
@SingleJsoImpl
interface Person {
String getName();
}
final class JsoPerson extends JavaScriptObject implements Person {
protected JsoPerson() {}
public native String getName() /*-{ return this.name; }-*/;
}
class MutablePerson implements Person {
private String name;
public MutablePerson(Person copyFrom) {this.person = copyFrom.getName();}
public String getName() {return name;}
public void setName(String name);
}
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: SuggestBox uprades
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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Issue 210 - demo index
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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR:IsFocusable interface
Sounds good. Do we need the verb in this case? How about just Focusable? On Wed, Dec 17, 2008 at 5:28 PM, Emily Crutcher e...@google.com wrote: Yep, that's the plan! On Wed, Dec 17, 2008 at 5:10 PM, Ray Ryan rj...@google.com wrote: Works for me. And IsFocusable extends no other interfaces, right? On Thu, Dec 18, 2008 at 7:18 AM, Emily Crutcher e...@google.com wrote: 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 or sorucesKeyboardEvents from the HasFocus interface without breaking an enormous amount of code. Therefore, my proposal is that we should do the following: Introduce a new interface, IsFocusable, and move all the HasFocus methods that are not deprecated into this new interface Have HasFocus extend IsFocusable. Deprecate the HasFocus interface. In TreeItem, HasFocus.getFocusableWidget becomes IsFocusable getFocusableWidget. -- 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: 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 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A couple more small tweaks to the gwt-incubator build target
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
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A couple more small tweaks to the gwt-incubator build target
Opened issue 209.
On Tue, Dec 16, 2008 at 10:52 AM, Emily Crutcher e...@google.com wrote:
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] Re: Review request: add super source dir to incubator demo build
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
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Review request: add super source dir to incubator demo build
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
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: HasValue is not ready for primetime
how about we narrow the scope of this conversation to CheckBox api repair. How about this: Deprecate CheckBox#isChecked and CheckBox#setChecked Introduce CheckBox#setFormValue Add copious javadoc to compare and contrast the two set...Value methods No objections here. While we're being cautious, here's an alternate approach that is even more guarded: * Leave is/setChecked as-is. * Add get/setFormValue. * Don't implement HasValue in CheckBox at all. After HasValue gets more exposure in trunk and GWT 1.6, solicit feedback as to whether CheckBox would benefit from implementing it or just add confusion. I don't propose that this is necessarily a better solution, just food for thought. On Thu, Dec 11, 2008 at 6:24 PM, Ray Ryan rj...@google.com wrote: Well put, RayC, thanks. MVC is exactly the intended point of HasValue. (Freeland, John, it's HasValueT, that's not being debated, fret ye not.) And you guys are right, I think, that we're wrong to paralyze ourselves with fears of future confusion with our still-vague-but-crystallizing-nicely notions of a data binding framework. The specific issue that got me to lob this grenade was a disgusted internal complaint by someone who has long been frustrated by our CheckBox's lack of access to the dom value field. When he saw the longed for method appear and do exactly the wrong thing, and in a manner redundant with isChecked... I like HasValue, but its application to CheckBox has produced very confusing little beastie. So, how about we narrow the scope of this conversation to CheckBox api repair. How about this: Deprecate CheckBox#isChecked and CheckBox#setChecked Introduce CheckBox#setFormValue Add copious javadoc to compare and contrast the two set...Value methods If this flies, are there other widgets that need the setFormValue method? rjrjr On Fri, Dec 12, 2008 at 7:42 AM, Ray Cromwell cromwell...@gmail.com wrote: IMHO, the concept of a Widget having a value is that it has only one value. The value can certainly be an object with multiple fields, or with conversion helper functions (String-Boolean), but it's one value with a normalized internal representation. For example, consider an USPostalAddressWidget, which HasValueUSPostalAddress. This widget is quite complex, with probably ample internal textboxes for each field (street, city, state, zip, suite, etc) and also validation. However, the widget conceptually has a single value: a USPostalAddress that can be get and set. In this context, I think it is clear that HasValue is really a Model-View interface. If it were a Table, it would be HasValueTableModel or HasValueTableData, for example. Probably the primary difference is HasValue doesn't require models to provide change listener interfaces. I don't believe that Data Binding and Model/View architectures are mutually exclusive. The main difference is, with MVC, typically, you build model POJOs, and build the View to be tightly coupled to the model interface, so that there is usually (but not always) a one to one correspondence between View and Model types. With Data Binding frameworks, the coupling is looser and you can have a many-to-one relationship, e.g bind POJO.fooField to Widget A and bind POJO.barField to WidgetB, or further, you can bind into composite widgets exposing their innards. Data Binding allows for more reuse since you can repurpose pojo models by slicing and dicing them with binding expressions, on the other hand, lots of bindings can get messy and make it harder to track what widgets deal with what data, especially if the bindings are dynamic or in a DSL. -Ray On Thu, Dec 11, 2008 at 11:49 AM, Isaac Truett itru...@gmail.com wrote: At the risk of seeming to hand-wave that problem away, I would say that any Widget seeking to implement HasValue twice is not a candidate for HasValue at all. HasValue is, by definition, for Widgets with a single distinct value. The value of a CheckBox is either a String or a Boolean (we've seen arguments either way) or it simply isn't a HasValue because it's a complex Widget with two equally important and independent values. On Thu, Dec 11, 2008 at 2:41 PM, John Tamplin j...@google.com wrote: On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: To be fair, my friend was extending TextBox---which came to implement HasValue, and thus acquired the colliding String getValue()---when he should have extended Composite (which doesn't) instead; that was my suggested resolution for him. He grumbled (but it 'is-a' TextBox, that should be extends), but conceded. However, the old HasValue is not parameterized, and implies something has *string* value, period. As applied to CheckBox, that's confusing-to-wrong. Isaac is correct that we can resolve this by making CheckBox not a HasValue, and keep the interface... but the discussion makes me think that HasValueT has merit
[gwt-contrib] Re: RR: HasValue is not ready for primetime
The HasValue interface's usefulness is entirely separable from any framework or library which might or might not be built on top of it. TelephoneTextBox is a great example of that. You could wrap a single TextBox in a composite that implements HasValueTelephoneNumber and another composite (TelephoneChooser?) that wraps three TextBoxes (Area Code, Exchange, and... whatever you call the last four numbers). Yet another implementation might use DropDownListBox to limit the available area codes (to area codes in a given state, for example). All of those can be treated as HasValueTelephoneNumber and have consistent, type-safe accessors defined by that interface. Not every Widget needs to implement HasValue. Widgets could be retrofitted later. And HasValue doesn't have to replace current accessors. TextBox.getText() could trivially delegate to getValue() and wouldn't even need to be deprecated. There is the potential for collision with any existing Widget extensions that define methods called getValue() or setValue(). That's unfortunate, but unavoidable when adding to an existing API. That should also be an understood risk when extending a class from another source. If you want to protect against changing API, encapsulation is much safer. I cannot agree more with the cautious spirit of this proposal, but I don't think unquantified fears about future data binding and validation work justify holding this up. HasValue did a brief stint in incubation and maybe it's been called up prematurely, but I don't think so. Consider HasValue on its own merits. On Wed, Dec 10, 2008 at 10:51 PM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: Without having actually looked at HasValue much, I did get pinged by a friend of mine who was annoyed that his overridden parameterized getValue() was now colliding with our String getValue()... looking at CheckBox, perhaps something like HasValueBoolean would be a better semantic. (It also might work better for my friend's case, which was basically a parameterized parent for IntegerTextBox, CurrencyTextBox, TelephoneTextBox, etc.) I think Ray's point is just that we'd rather not have GWT wind up tied to something half-thought-out, but have to support it three years from now as well as whatever we discover we want instead. Fearing that we just stepped onto such a route, he's trying to step back before it's too late and he's stuck. It'd be nice if such a thing could drop into the incubator to bake, of course. grin On Wed, Dec 10, 2008 at 9:00 PM, Isaac Truett itru...@gmail.com wrote: We'll need a general stick-a-value-in-take-a-value-out mechanism, the HasValue interface may not be the right one, and we'd prefer not to lead with it in isolation from the framework as a whole. If HasValue isn't a contract that you want to honor, that's one thing. But saying that it would interfere with a data binding or validation framework just doesn't seem accurate. Even if you end up not using HasValue as part of those frameworks, it isn't a loss. It's just not used. HasValue consolidates all of the separate accessors that Widgets have to define anyway and gives them a common API. That's not stepping on any other API or framework's toes. Yes, and the lack of access to the underlying value attribute has long been confusing to folks with an HTML background. Adding a setValue method that some have considered to be missing, but having it not apply to the checkbox value is just plain confusing. I don't necessarily agree with this position, but I can accept that others might. So punt on CheckBox for now. Nothing says every Widget has to implement HasValue. Do you actually anticipate finding a replacement for HasValue that will fit every current and future Widget perfectly? On Wed, Dec 10, 2008 at 8:35 PM, Ray Ryan rj...@google.com wrote: On Thu, Dec 11, 2008 at 12:28 PM, Isaac Truett itru...@gmail.com wrote: Reactions? Puzzlement. It stands a good chance of interfering with nascent data binding / validation work. Care to elaborate on this? We'll need a general stick-a-value-in-take-a-value-out mechanism, the HasValue interface may not be the right one, and we'd prefer not to lead with it in isolation from the framework as a whole. And its application to CheckBox is just plain wrongheaded and confusing. (CheckBox#setValue doesn't actually set the input element's value attribute--oops.) When has GWT's CheckBox ever had a value in the HTML sense? As a Widget, it represents a boolean value. Yes, and the lack of access to the underlying value attribute has long been confusing to folks with an HTML background. Adding a setValue method that some have considered to be missing, but having it not apply to the checkbox value is just plain confusing. Obviously you're not telling the whole story here. Well, no, really that's it. On Wed, Dec 10, 2008 at 7:35 PM, Ray Ryan
[gwt-contrib] Re: RR: HasValue is not ready for primetime
At the risk of seeming to hand-wave that problem away, I would say that any Widget seeking to implement HasValue twice is not a candidate for HasValue at all. HasValue is, by definition, for Widgets with a single distinct value. The value of a CheckBox is either a String or a Boolean (we've seen arguments either way) or it simply isn't a HasValue because it's a complex Widget with two equally important and independent values. On Thu, Dec 11, 2008 at 2:41 PM, John Tamplin j...@google.com wrote: On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: To be fair, my friend was extending TextBox---which came to implement HasValue, and thus acquired the colliding String getValue()---when he should have extended Composite (which doesn't) instead; that was my suggested resolution for him. He grumbled (but it 'is-a' TextBox, that should be extends), but conceded. However, the old HasValue is not parameterized, and implies something has *string* value, period. As applied to CheckBox, that's confusing-to-wrong. Isaac is correct that we can resolve this by making CheckBox not a HasValue, and keep the interface... but the discussion makes me think that HasValueT has merit, and for example a CheckBox would be HasValueBoolean and a TextBox would be HasValueString (my friend should still make Composites, with HasValueTelephoneStationNumber, and not extend TextBox). But if we go with HasValue (unparameterized), that's a breaking change to make later (I guess we'd have to make HasTypedValueT instead, and have HasValue come to extend HasTypedValueString), and so I'm still happy to pause and think a bit more. (Do we like HasValueT, where T is widget-specific for whatever widgets have values??) One problem is that due to type erasure you cannot implement multiple copies of this interface (such as HasValueBoolean and HasValueString). For a hypothetical checkbox, you might well want a boolean value for checked or not, as well as the string value (ie, what it would post as in a form submit). Other than that, I think the generic version is the way to go if it is kept. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: HasValue is not ready for primetime
Reactions? Puzzlement. It stands a good chance of interfering with nascent data binding / validation work. Care to elaborate on this? And its application to CheckBox is just plain wrongheaded and confusing. (CheckBox#setValue doesn't actually set the input element's value attribute--oops.) When has GWT's CheckBox ever had a value in the HTML sense? As a Widget, it represents a boolean value. Obviously you're not telling the whole story here. On Wed, Dec 10, 2008 at 7:35 PM, Ray Ryan [EMAIL PROTECTED] wrote: As much as I like the spirit HasValue interface introduced with the new event handlers, I think we've rushed it, and that it should be removed for 1.6. It stands a good chance of interfering with nascent data binding / validation work. And its application to CheckBox is just plain wrongheaded and confusing. (CheckBox#setValue doesn't actually set the input element's value attribute--oops.) I'd like to take it out. The CL to do this will: Delete the HasValue interface Leave DatePicker as is Delete TextBoxBase#setValue(String), and add rename TextBoxBase#setValue(String, Boolean) to setText(String, Boolean) Delete CheckBox#SetValue, and make it stop throwing ValueChange events. Reactions? rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: HasValue is not ready for primetime
We'll need a general stick-a-value-in-take-a-value-out mechanism, the HasValue interface may not be the right one, and we'd prefer not to lead with it in isolation from the framework as a whole. If HasValue isn't a contract that you want to honor, that's one thing. But saying that it would interfere with a data binding or validation framework just doesn't seem accurate. Even if you end up not using HasValue as part of those frameworks, it isn't a loss. It's just not used. HasValue consolidates all of the separate accessors that Widgets have to define anyway and gives them a common API. That's not stepping on any other API or framework's toes. Yes, and the lack of access to the underlying value attribute has long been confusing to folks with an HTML background. Adding a setValue method that some have considered to be missing, but having it not apply to the checkbox value is just plain confusing. I don't necessarily agree with this position, but I can accept that others might. So punt on CheckBox for now. Nothing says every Widget has to implement HasValue. Do you actually anticipate finding a replacement for HasValue that will fit every current and future Widget perfectly? On Wed, Dec 10, 2008 at 8:35 PM, Ray Ryan [EMAIL PROTECTED] wrote: On Thu, Dec 11, 2008 at 12:28 PM, Isaac Truett [EMAIL PROTECTED] wrote: Reactions? Puzzlement. It stands a good chance of interfering with nascent data binding / validation work. Care to elaborate on this? We'll need a general stick-a-value-in-take-a-value-out mechanism, the HasValue interface may not be the right one, and we'd prefer not to lead with it in isolation from the framework as a whole. And its application to CheckBox is just plain wrongheaded and confusing. (CheckBox#setValue doesn't actually set the input element's value attribute--oops.) When has GWT's CheckBox ever had a value in the HTML sense? As a Widget, it represents a boolean value. Yes, and the lack of access to the underlying value attribute has long been confusing to folks with an HTML background. Adding a setValue method that some have considered to be missing, but having it not apply to the checkbox value is just plain confusing. Obviously you're not telling the whole story here. Well, no, really that's it. On Wed, Dec 10, 2008 at 7:35 PM, Ray Ryan [EMAIL PROTECTED] wrote: As much as I like the spirit HasValue interface introduced with the new event handlers, I think we've rushed it, and that it should be removed for 1.6. It stands a good chance of interfering with nascent data binding / validation work. And its application to CheckBox is just plain wrongheaded and confusing. (CheckBox#setValue doesn't actually set the input element's value attribute--oops.) I'd like to take it out. The CL to do this will: Delete the HasValue interface Leave DatePicker as is Delete TextBoxBase#setValue(String), and add rename TextBoxBase#setValue(String, Boolean) to setText(String, Boolean) Delete CheckBox#SetValue, and make it stop throwing ValueChange events. Reactions? rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: 1.6 date picker question
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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed Modification to PopupPanel
Other Solutions: We considered passing the event preview down the existing stack of EventPreview, which fixes the problem for more than just PopupPanels. However, we think this approach is overkill because the problem really doesn't manifest itself in other widgets. What about GlassPanel in the Incubator? Sounds like throwing a GlassPanel into the mix would break things since it isn't a subclass of PopupPanel and does it's own event previewing. On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca [EMAIL PROTECTED] wrote: Contributors - Summary: In the current implementation of PopupPanel, a PopupPanel with autoHide enabled will not autoHide if another Widget (such as another PopupPanel) steals the event preview. In practice, this means that if a PopupPanel is opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no longer autoHide. Consider an example where you have a SuggestBox inside of a PopupPanel that is autoHide. If you start typing in the SuggestBox, it opens a PopupPanel of suggestions. You then click outside the original popup and expect it to disappear. Instead, only the SuggestBox popup disappears. In this case, the PopupPanels are related, but in some cases they are not. If you use a sticky PopupPanel (stays open for a while, ex. a debug menu or log) in your app, it may steal preview from an autoHide PopupPanel, and you have to close one to close the other. Proposed Solution: == I propose that we add a static stack of PopupPanels to the PopupPanel class. As popups are shown and hidden, they are added and removed from the stack. When a popup recieves an event preview, it passes the event down the stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel that is modal. The first modal PopupPanel (which blocks events by definition) will end the event preview chain. Example: === Consider the following stack of PopupPanels, where the top panel is the last one that is opened: popup6 (autoHide) popup5 popup4 (autoHide) popup3 (autoHide) popup2 (modal) popup1 (autoHide) popup0 (modal) Now lets say you click on popup4: 1. Popup6 previews the event. AutoHide is enabled, so it will hide. (NOTE: usually, only popup6 gets to preview the event) 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so ignore it. 3. Popup4 previews the event. AutoHide is enabled, but the event occured over Popup4, so it is ignored. 4. Popup3 previews the event. AutoHide is enabled, so it will hide. 5. Popup2 previews the event. Modal is enabled, so it ends the chain. Popup1 and Popup0 never preview the event, so they both remain open. Other Solutions: We considered passing the event preview down the existing stack of EventPreview, which fixes the problem for more than just PopupPanels. However, we think this approach is overkill because the problem really doesn't manifest itself in other widgets. Thanks, John LaBanca [EMAIL PROTECTED] --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed Modification to PopupPanel
Sounds good. I don't do a lot with event preview, but it seems reasonable that it should follow the new event model. On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher [EMAIL PROTECTED] wrote: What about deprecating the old DOM.addEventPreview and creating an DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and has some specialized methods to stop the event from going down the GWT preview event chain. On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett [EMAIL PROTECTED] wrote: Other Solutions: We considered passing the event preview down the existing stack of EventPreview, which fixes the problem for more than just PopupPanels. However, we think this approach is overkill because the problem really doesn't manifest itself in other widgets. What about GlassPanel in the Incubator? Sounds like throwing a GlassPanel into the mix would break things since it isn't a subclass of PopupPanel and does it's own event previewing. On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca [EMAIL PROTECTED] wrote: Contributors - Summary: In the current implementation of PopupPanel, a PopupPanel with autoHide enabled will not autoHide if another Widget (such as another PopupPanel) steals the event preview. In practice, this means that if a PopupPanel is opened on top of an autoHide PopupPanel, the autoHide PopupPanel will no longer autoHide. Consider an example where you have a SuggestBox inside of a PopupPanel that is autoHide. If you start typing in the SuggestBox, it opens a PopupPanel of suggestions. You then click outside the original popup and expect it to disappear. Instead, only the SuggestBox popup disappears. In this case, the PopupPanels are related, but in some cases they are not. If you use a sticky PopupPanel (stays open for a while, ex. a debug menu or log) in your app, it may steal preview from an autoHide PopupPanel, and you have to close one to close the other. Proposed Solution: == I propose that we add a static stack of PopupPanels to the PopupPanel class. As popups are shown and hidden, they are added and removed from the stack. When a popup recieves an event preview, it passes the event down the stack and lets each PopupPanel preview it UNTIL it reaches a PopupPanel that is modal. The first modal PopupPanel (which blocks events by definition) will end the event preview chain. Example: === Consider the following stack of PopupPanels, where the top panel is the last one that is opened: popup6 (autoHide) popup5 popup4 (autoHide) popup3 (autoHide) popup2 (modal) popup1 (autoHide) popup0 (modal) Now lets say you click on popup4: 1. Popup6 previews the event. AutoHide is enabled, so it will hide. (NOTE: usually, only popup6 gets to preview the event) 2. Popup5 previews the event. Neither autoHide nor modal is enabled, so ignore it. 3. Popup4 previews the event. AutoHide is enabled, but the event occured over Popup4, so it is ignored. 4. Popup3 previews the event. AutoHide is enabled, so it will hide. 5. Popup2 previews the event. Modal is enabled, so it ends the chain. Popup1 and Popup0 never preview the event, so they both remain open. Other Solutions: We considered passing the event preview down the existing stack of EventPreview, which fixes the problem for more than just PopupPanels. However, we think this approach is overkill because the problem really doesn't manifest itself in other widgets. Thanks, John LaBanca [EMAIL PROTECTED] -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: incubator code review
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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
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 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: Don't forget CachedTableModel.clearCache()
If TableModel had an abstract clearCache method, I could make: myPagingGrid.getTableModel().clearCache(); myPagingGrid.gotoPage(0, true); That would be more clean imho. But it wouldn't, you see, because not all TableModels have caching. You're trying to move a method higher up the inheritance chain where it doesn't belong. The fact that your PST uses a caching TableModel is an implementation detail of your application. You should extend or encapsulate PST and your TableModel and provide/override a method in that new object that handles clearing the cache before refreshing the page. On Sat, Nov 22, 2008 at 8:00 PM, Geraldo Lopes [EMAIL PROTECTED] wrote: Hi, I'm making a crud application that uses PagingScrollTable. It consists of a paging grid and a form that reflects the current selected row. I use the form to make query by example, so I start with a group of values and depending on the search I need to populate the grid with completely different set of values. After the user click the search button I was trying to reload the values with : myPagingGrid.gotoPage(0, true); // true to force reload. I was getting strange results, with values of the last search being mixed with the ones of the current search. My mistake was I'm using CachedTableModel, that encapsulate my real table mode and it was keeping values from the last search around. final CachedTableModelCliente cachedTableModel = new CachedTableModelCliente(tableModel); So cachedTableModel.clearCache() before myPagingGrid.gotoPage(0, true) solved the problem. Just wondering: CachedTableModel extends MutableTableModel which extends TableModel, and PagingScrollTable points to TableModel, so I can't invoke clear cache via PagingScrollTable. Instead I have to pass a instance to PagingScrollTable and CachedTableModel to be able to: cachedTableModel.clearCache(); myPagingGrid.gotoPage(0, true); If TableModel had an abstract clearCache method, I could make: myPagingGrid.getTableModel().clearCache(); myPagingGrid.gotoPage(0, true); That would be more clean imho. Thanks for the marvelous work you are doing. Geraldo Lopes --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding PopupPanel.showBelow
On Wed, Nov 19, 2008 at 10:37 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
On Wed, Nov 19, 2008 at 10:08 AM, Isaac Truett [EMAIL PROTECTED] wrote:
Seems like this would be useful for other orientations -- showAbove,
showBefore, showAfter and combinations for easily positioning popups
We were not planning on it, because the show below case is by far the most
useful. However, we should also not box ourselves into corners, so what if
we renamed the method to showRelativeTo(UIObject object), with the javadoc
saying that it, by default shows below. Then, if we do decide to eventually
introduce orientations we would have two methods:
// defaults to showing the popup below
showRelativeTo(UiObject object)
// specify default.
showRelativeTo(UiObject object, Orientation)
Sounds good to me.
at the corners of target. With that in mind, would this be the first
of 8 different methods for relative positioning of popups or would a
showRelativeTo(UIObject, Orientation) method be better to avoid method
proliferation?
Also, hideOnWindowResize seems unrelated to the showing of the popup.
Was it part of the API in DropDownPanel for reasons other than
convenience?
It was there for convinience, as, in general, if you are relatively
positioning a popup under a widget, you often want to close it on window
resize. However, the tricky code is the showRelativeTo, if we end up
duplicating the hiding of the popup in a couple of places, that is less of a
problem, so we can take the boolean out.
I have a few general-purpose Listener implementations such as
HoverListener that applies a style onMouseOver and EnterKeyListener
that executes an arbitrary Command when the enter key is pressed. I've
considered suggesting such things for GWT/Incubator but thought it
would be seen as too trivial, or better suited to a third-party
library. Perhaps such a generic HideOnWindowResizeListener/Handler
implementation would be useful if this is going to be found commonly
in GWT code. It could be an impl package class if supporting it as
public API is undesirable.
On Wed, Nov 19, 2008 at 9:58 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
We are starting to migrate some of the functionality from DropDownPanel
in
incubator to PopupPanel.
Therefore, we are proposing to add the following method to PopupPanel.
It
will be used by SuggestBox and DateBox:
/**
* Normally, the popup is positioned directly below the relative
target,
with
* its left edge aligned with the left edge of the target. Depending
on
the
* width and height of the popup and the distance from the target to
the
* bottom and right edges of the window, the popup may be displayed
directly
* above the target, and/or its right edge may be aligned with the
right
edge
* of the target depending upon where it fits.
*
* @param target the target to show the popup below
* @param hideOnWindowResize hide the popup if the window is resized
*/
public final void showBelow(final UIObject target,
final boolean hideOnWindowResize) {
...
}
--
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: Code Review, copies LazyPanel to 1.6 from incubator
1. I don't like the fact that it's a panel, inheriting a useless list and extra API, and find myself wishing for, say, LazyComposite instead. Is there any particular reason it wasn't written that way originally? I agree that a Composite seems more flexible. In fact, I've been toying with something even more abstract, using an Initializable interface, InitializableComposite, and InitializationEvent. It might be overkill; I don't have a really compelling use case so far. On Wed, Nov 19, 2008 at 11:50 AM, Ray Ryan [EMAIL PROTECTED] wrote: Here's the bulk of the work introducing LazyPanel. I'll send a follow up patch that reworks ShowCase to use it soon. You'll note that the javadoc references an example that doesn't exist yet. It's written, but I'll send a separate patch when it's been tested. Issues: 1. I don't like the fact that it's a panel, inheriting a useless list and extra API, and find myself wishing for, say, LazyComposite instead. Is there any particular reason it wasn't written that way originally? 2. I chatted with jlabanca, and we think it would be a good idea to tweak DisclosurePanel so that it calls setVisible(true) on its wrapped children before exposing them, to make it LazyPanel friendly the same way that DeckPanel and StackPanel already are. rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Code Review, copies LazyPanel to 1.6 from incubator
Your justification for LazyPanel came in as I was replying and I agree completely. I was actually musing on my initialization interface and event idea being unnecessary. On Wed, Nov 19, 2008 at 12:36 PM, Emily Crutcher [EMAIL PROTECTED] wrote: On Wed, Nov 19, 2008 at 12:03 PM, Isaac Truett [EMAIL PROTECTED] wrote: 1. I don't like the fact that it's a panel, inheriting a useless list and extra API, and find myself wishing for, say, LazyComposite instead. Is there any particular reason it wasn't written that way originally? I agree that a Composite seems more flexible. In fact, I've been toying with something even more abstract, using an Initializable interface, InitializableComposite, and InitializationEvent. It might be overkill; I don't have a really compelling use case so far. I think the compelling use case is for a simple widget container, as what we really want to say is that I contain a widget that can be removed from me. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR:GwtEventPreview
Can you think of any other relevant use cases?
4. Uncaught exception in onGwtEventPreview().
On Tue, Nov 11, 2008 at 10:25 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
The naming was mimicking the EventPreview interface we have for the
underlying native events. Don't mind changing it, but it seems like
the consistency is nice.
I think the testing should be fairly trivial as we have three use cases.
no event preview set on a handler manager.
an event preview set on a handler manager that returns false
an event preview set on a handler manager that returns true
Can you think of any other relevant use cases? I'll wait until after the
kids are asleep tonight to implement, so if any of you can think of any
objections throughout the day, please pipe up! Especially any reason that
would lead us to believe that his is not the canonical solution we want to
implement.
On Tue, Nov 11, 2008 at 10:11 AM, Ray Ryan [EMAIL PROTECTED] wrote:
It's fine with me if the trivial amount of time it will take to add
includes time for test coverage.
On naming, how about GwtEventPreviewer and setEventPreviewer.
rjrjr
On Tue, Nov 11, 2008 at 6:37 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
I've managed to convince myself that it would be a trivial amount of work
to introduce a GwtEventPreview interface into the events package and that
the change would be a good one. In specific we would have:
public interface GwtEventPreview {
boolean onGwtEventPreview(GwtEvent event);
}
and, in HandlerManager:
public void setGwtEventPreview(GwtEventPreview preview)
Then, in the final fireEvent method, if a preview has been installed, the
event is routed through the preview first and is only fired if the preview
returns true.
Can anyone think of any problems with this logic, any reason this change
would take more then a few minutes to create, or any potentially better
solutions which we might want to use instead? As we can certainly wait
until GWT 2.0 to introduce something like this if we can think of
any conceivable objections.
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: Turning off runtime checks
I'm curious what things you're referring to here. Generally, I think we're pretty open to more checks in hosted mode. As an example, hosted mode always runs with assertions enabled. More assertions are exactly what I've been hoping for. The one case that's stuck with me was issue 2365. As I understand it, those assertions (and the check method, if only called in assertions) will all be compiled away, so there's no size or performance penalty in web mode. On Tue, Nov 11, 2008 at 10:43 AM, Bruce Johnson [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 10:38 AM, Isaac Truett [EMAIL PROTECTED] wrote: We've been kicking around the idea of an unsafe but fast compile for exactly this reason. I always thought the compile was unsafe already. Only for things that are truly unaffordable, like null checks on every object access. I've even suggested adding more hosted mode-only checks and been rejected because of the cost of such runtime validations. I'm curious what things you're referring to here. Generally, I think we're pretty open to more checks in hosted mode. As an example, hosted mode always runs with assertions enabled. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Turning off runtime checks
We've been kicking around the idea of an unsafe but fast compile for exactly this reason. I always thought the compile was unsafe already. Hasn't the GWT philosophy been to perform type safety/bounds/null checks only in hosted mode, if at all? Are there many such checks currently left in compiled code? I've even suggested adding more hosted mode-only checks and been rejected because of the cost of such runtime validations. On Tue, Nov 11, 2008 at 10:30 AM, Scott Blum [EMAIL PROTECTED] wrote: We've been kicking around the idea of an unsafe but fast compile for exactly this reason. OTOH, there are a couple of things we could do to make the type checks faster even in the short term: 1) Do actual null tracking so as to omit the null check part in many cases. 2) Get away from using typeIdArray in favor of having cast information accessible directly off the object, which should be faster. 3) Make sure it's inlined in all cases. On Tue, Nov 11, 2008 at 2:14 AM, Ray Cromwell [EMAIL PROTECTED] wrote: Heads up guys, I just profiled my app trying to squeeze every last drop of performance out for speedups on the iPhone which has slow Javascript, and I noticed that the canCastUnsafe/dynamicCast functions are collectively eating up 8.5% of the total runtime. It seems that the sole purpose of dynamicCast() is to throw a ClassCastException where the JVM would, but in production web-deployment mode, I would honestly prefer the option of having these checks omitted. Yes, there are some cases where throwing the exception would give the end user a better error message, but if the user is able to reproduce incorrect behavior, I think I would prefer to direct them to a debug build/permutation which has the checks. It seems the major place where this could trip up legitimate code is if someone was triggering CCEs on purpose and expecting to catch them with an exception handler. The main reason these checks are being inserted is because I switched from using a custom collection, to a ListFoo, and the compiler appears to be unable to use the generic type information of the JField to determine that the cast is unneccessary. Anyway, the question for discussion is, should the compiler have an -O2 mode which eliminates range checks, runtime cast checks, etc -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Review request: JSE (Invalid argument) in AbstractScrollTable
John, I wanted to run this one-liner by you before committing. I'm seeing the JSE below in hosted mode when the body of my PagingScrollTable is empty and has 0 height. The headerHeight is positive and (totalHeight - headerHeight - footerHeight) comes out to a negative number. The patch following the stacktrace fixes the problem. Thanks, Isaac [ERROR] Uncaught exception escaped com.google.gwt.core.client.JavaScriptException: (Error): Invalid argument. number: -2147024809 description: Invalid argument. at com.google.gwt.dom.client.Style$.setProperty$(Native Method) at com.google.gwt.user.client.DOM.setStyleAttribute(DOM.java:1201) at com.google.gwt.gen2.table.client.AbstractScrollTable.resizeTablesVerticallyNow(AbstractScrollTable.java:1375) at com.google.gwt.gen2.table.client.AbstractScrollTable$1.execute(AbstractScrollTable.java:614) at com.google.gwt.user.client.CommandExecutor.doExecuteCommands(CommandExecutor.java:311) at com.google.gwt.user.client.CommandExecutor$2.run(CommandExecutor.java:206) at com.google.gwt.user.client.Timer.fireImpl(Timer.java:164) at com.google.gwt.user.client.Timer.fireAndCatch(Timer.java:150) at com.google.gwt.user.client.Timer.fire(Timer.java:142) Index: src/com/google/gwt/gen2/table/client/AbstractScrollTable.java === --- src/com/google/gwt/gen2/table/client/AbstractScrollTable.java (revision 1195) +++ src/com/google/gwt/gen2/table/client/AbstractScrollTable.java (working copy) @@ -1395,7 +1395,7 @@ DOM.setStyleAttribute(footerWrapper, height, footerHeight + px); } DOM.setStyleAttribute(dataWrapper, height, -(totalHeight - headerHeight - footerHeight) + px); +Math.max(totalHeight - headerHeight - footerHeight, 0) + px); DOM.setStyleAttribute(dataWrapper, overflow, hidden); DOM.setStyleAttribute(dataWrapper, overflow, auto); scrollTables(true); --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: FYI: code reviews done through our googlecode project will CC this list.
I'm guessing the answer is no but I'll throw this out there... Is it possible to have the code review comment mails contain the comment history for each line of code that is commented on? Right now the comments in the emails are out of context. When each email has comments for several different lines, and each comment responds to a previous comment on that line, it's hard to follow the thread of conversation. When this was all done directly via email, the comments were easy to follow as everybody commented inline in the body of the previous email. An alternative approach might be to have each comment in the email contain a link to the comment thread in the full review page. On Wed, Nov 5, 2008 at 2:19 PM, Kelly Norton [EMAIL PROTECTED] wrote: I just wanted people to be aware of this. I've changed the settings in our project to always CC the code review comments to this list. /kel -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: FYI: code reviews done through our googlecode project will CC this list.
The most useful information I found was buried a few layers under the email: Details are at http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=%2Fbranches%2F1_6_clean_events 1. Follow this link at the top of the email. Comment by [EMAIL PROTECTED], Today (10 minutes ago) 4 line-by-line comments 2. Expand this section at the bottom of the page. /branches/1_6_clean_events/user/src/com/google/gwt/core/client/impl/RawJsMapImpl.java r3958 line 31: 3. Follow this link to the source file with comments in line. I agree with John that the contents of the page at step #1 aren't very useful (to me, at least). I would instead include in the email all of the links into the code itself, as in step #3 -- that's where I need to be understand things. Now, I haven't actually participated in this as a reviewer, so maybe that first link makes more sense for someone in that role. On Thu, Nov 6, 2008 at 11:22 AM, John Tamplin [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 12:12 PM, Isaac Truett [EMAIL PROTECTED] wrote: Is it possible to have the code review comment mails contain the comment history for each line of code that is commented on? Right now the comments in the emails are out of context. When each email has comments for several different lines, and each comment responds to a previous comment on that line, it's hard to follow the thread of conversation. When this was all done directly via email, the comments were easy to follow as everybody commented inline in the body of the previous email. I agree -- the current email that is sent is nearly worthless for trying to follow if you aren't actually involved in the review. I think it would actually be better to just get email saying review comments have been made and a link to where you can read them (ie, just the top part of the current email, so I am not tempted to waste time reading them). The real problem is that even once you get to the web site, the comments are not arranged usefully, as they are still broken down by who made the comment rather than files with comments. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Simple, safe and restricted?
Daniel, Would accessors to interfaces meet your needs? Is there a method on TextBox that you need access to that isn't defined in an interface? On Mon, Nov 3, 2008 at 1:23 PM, Isaac Truett [EMAIL PROTECTED] wrote: Exposing the guts of a widget to developers might be dangerous, but if you want to break the widget or the underlying dom you may find ways to do it anyway. Sure. I just think you should keep that internal access as narrow in scope as possible. Public API is not only an invitation to meddle, but a commitment to an API contract. What about declaring risky members protected so that developers need at least to have some knowledge about subclassing in order to access them? I think protected access to members is better, but I'd suggest leaving the members themselves private and adding protected getters. And either make the getter final or have the parent class always call getFoo() instead of referencing the private member foo. That way if subclasses can override getFoo() it should still work as expected. I think it is the worst solution to force people to access private members/methods by patching the sources and replacing them based on classpath loading order. I think there will still be cases where things should remain private and difficult to access. Exposing a getTextBox() method, for example, means a commitment to always use a TextBox internally. Most of the time, that's probably okay. but if you can get away with just exposing methods to add listeners or expose accessors to interfaces (protected HasValueString getHasValue(), for example), that leaves you the freedom to change the internals later without breaking API. On Mon, Nov 3, 2008 at 1:10 PM, dflorey [EMAIL PROTECTED] wrote: I want to move the discussion started in http://code.google.com/p/google-web-toolkit-incubator/issues/detail?id=174 to a separate thread. I came across many situations where it was very annoying that members/ methods of widgets have been declared private. Exposing the guts of a widget to developers might be dangerous, but if you want to break the widget or the underlying dom you may find ways to do it anyway. What about declaring risky members protected so that developers need at least to have some knowledge about subclassing in order to access them? I'm fine with public getters and setters, but as itruett mentioned it might be too easy to break the widget. I think it is the worst solution to force people to access private members/methods by patching the sources and replacing them based on classpath loading order. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Simple, safe and restricted?
Exposing the guts of a widget to developers might be dangerous, but if you want to break the widget or the underlying dom you may find ways to do it anyway. Sure. I just think you should keep that internal access as narrow in scope as possible. Public API is not only an invitation to meddle, but a commitment to an API contract. What about declaring risky members protected so that developers need at least to have some knowledge about subclassing in order to access them? I think protected access to members is better, but I'd suggest leaving the members themselves private and adding protected getters. And either make the getter final or have the parent class always call getFoo() instead of referencing the private member foo. That way if subclasses can override getFoo() it should still work as expected. I think it is the worst solution to force people to access private members/methods by patching the sources and replacing them based on classpath loading order. I think there will still be cases where things should remain private and difficult to access. Exposing a getTextBox() method, for example, means a commitment to always use a TextBox internally. Most of the time, that's probably okay. but if you can get away with just exposing methods to add listeners or expose accessors to interfaces (protected HasValueString getHasValue(), for example), that leaves you the freedom to change the internals later without breaking API. On Mon, Nov 3, 2008 at 1:10 PM, dflorey [EMAIL PROTECTED] wrote: I want to move the discussion started in http://code.google.com/p/google-web-toolkit-incubator/issues/detail?id=174 to a separate thread. I came across many situations where it was very annoying that members/ methods of widgets have been declared private. Exposing the guts of a widget to developers might be dangerous, but if you want to break the widget or the underlying dom you may find ways to do it anyway. What about declaring risky members protected so that developers need at least to have some knowledge about subclassing in order to access them? I'm fine with public getters and setters, but as itruett mentioned it might be too easy to break the widget. I think it is the worst solution to force people to access private members/methods by patching the sources and replacing them based on classpath loading order. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: inability to set stylename on Panel cells
I don't know what a panel cell is but if you're talking about table cells, try a CellFormatter. And you'll reach a wider audience if you post development questions on the developer forum instead of the contributor forum. On Fri, Oct 31, 2008 at 8:47 AM, Charles Fry [EMAIL PROTECTED] wrote: I haven't been able to figure out any way to set style names on panel cells, which in my current situation is problematic. Am I missing something, or is that a missing feature? Charles --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
