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 -~----------~----~----~----~------~----~------~--~---
