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