Good point! Joel, where are your trigger event methods going?
On Wed, Dec 3, 2008 at 4:24 PM, John LaBanca <[EMAIL PROTECTED]> wrote: > +1 > > I think DOM is on its way out. Maybe we can add the method to Window, > Document, or even Event? > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > On Wed, Dec 3, 2008 at 4:19 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > >> >> Sounds good. I don't do a lot with event preview, but it seems >> reasonable that it should follow the new event model. >> >> On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: >> > What about deprecating the old DOM.addEventPreview and creating an >> > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent >> and >> > has some specialized methods to stop the event from going down the GWT >> > preview event chain. >> > >> > >> > >> > >> > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >> >> >> > Other Solutions: >> >> > ============ >> >> > We considered passing the event preview down the existing stack of >> >> > EventPreview, which fixes the problem for more than just PopupPanels. >> >> > However, we think this approach is overkill because the problem >> really >> >> > doesn't manifest itself in other widgets. >> >> >> >> What about GlassPanel in the Incubator? Sounds like throwing a >> >> GlassPanel into the mix would break things since it isn't a subclass >> >> of PopupPanel and does it's own event previewing. >> >> >> >> >> >> On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> >> wrote: >> >> > Contributors - >> >> > >> >> > Summary: >> >> > ======== >> >> > In the current implementation of PopupPanel, a PopupPanel with >> autoHide >> >> > enabled will not autoHide if another Widget (such as another >> PopupPanel) >> >> > steals the event preview. In practice, this means that if a >> PopupPanel >> >> > is >> >> > opened on top of an autoHide PopupPanel, the autoHide PopupPanel will >> no >> >> > longer autoHide. >> >> > >> >> > Consider an example where you have a SuggestBox inside of a >> PopupPanel >> >> > that >> >> > is autoHide. If you start typing in the SuggestBox, it opens a >> >> > PopupPanel >> >> > of suggestions. You then click outside the original popup and expect >> it >> >> > to >> >> > disappear. Instead, only the SuggestBox popup disappears. In this >> >> > case, >> >> > the PopupPanels are related, but in some cases they are not. If you >> use >> >> > a >> >> > sticky PopupPanel (stays open for a while, ex. a debug menu or log) >> in >> >> > your >> >> > app, it may steal preview from an autoHide PopupPanel, and you have >> to >> >> > close >> >> > one to close the other. >> >> > >> >> > >> >> > Proposed Solution: >> >> > ============== >> >> > I propose that we add a static stack of PopupPanels to the PopupPanel >> >> > class. As popups are shown and hidden, they are added and removed >> from >> >> > the >> >> > stack. When a popup recieves an event preview, it passes the event >> down >> >> > the >> >> > stack and lets each PopupPanel preview it UNTIL it reaches a >> PopupPanel >> >> > that >> >> > is modal. The first modal PopupPanel (which blocks events by >> >> > definition) >> >> > will end the event preview chain. >> >> > >> >> > >> >> > Example: >> >> > ======= >> >> > Consider the following stack of PopupPanels, where the top panel is >> the >> >> > last >> >> > one that is opened: >> >> > popup6 (autoHide) >> >> > popup5 >> >> > popup4 (autoHide) >> >> > popup3 (autoHide) >> >> > popup2 (modal) >> >> > popup1 (autoHide) >> >> > popup0 (modal) >> >> > >> >> > Now lets say you click on popup4: >> >> > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. >> >> > (NOTE: >> >> > usually, only popup6 gets to preview the event) >> >> > 2. Popup5 previews the event. Neither autoHide nor modal is enabled, >> so >> >> > ignore it. >> >> > 3. Popup4 previews the event. AutoHide is enabled, but the event >> >> > occured >> >> > over Popup4, so it is ignored. >> >> > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. >> >> > 5. Popup2 previews the event. Modal is enabled, so it ends the >> chain. >> >> > >> >> > Popup1 and Popup0 never preview the event, so they both remain open. >> >> > >> >> > >> >> > Other Solutions: >> >> > ============ >> >> > We considered passing the event preview down the existing stack of >> >> > EventPreview, which fixes the problem for more than just PopupPanels. >> >> > However, we think this approach is overkill because the problem >> really >> >> > doesn't manifest itself in other widgets. >> >> > >> >> > Thanks, >> >> > John LaBanca >> >> > [EMAIL PROTECTED] >> >> > >> >> > > >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > "There are only 10 types of people in the world: Those who understand >> > binary, and those who don't" >> > >> > > >> > >> >> >> > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
