Emily, My requirements are much simpeler, I just need a way to get notified of all events that happens in GWT.
When I notice no more mouse or keyboard events, I have to popup a modal dialog that blocks the UI. Since GWT already effectively has one method that gets called to dispatch the actual event, it would be nice if I could just register somewhere a listener that could listen along. The Preview mechanism uses a stack so that is not an option for me, unless I make sure that all popup panels use a preview listener that also trigger my inactivity listener. That can work, but as usual with bigger projects: I am not the only developer and the others do not always look around much when adding UI components. As a consequence when I implement something I need to enforce it in one place and be done with it. David On Thu, Dec 4, 2008 at 4:07 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > They are related, so it may be possible to unify them, but I have not given > it enough thought to be sure. I'd love to see a proposal if you have one in > mind? > > Cheers, > > Emily > > > On Thu, Dec 4, 2008 at 2:44 AM, Ray Cromwell <[EMAIL PROTECTED]>wrote: > >> >> Emily, >> Would my various proposals for a pluggable event propagation >> mechanism help allow us to address this in a more generalized matter? >> >> -Ray >> >> On Wed, Dec 3, 2008 at 11:14 AM, 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 -~----------~----~----~----~------~----~------~--~---
