Feel free to see the attached patch in progress.  I need to add unit tests
and do some testing, but this is a good chance for people to offer their
opinions.

Thanks,
John LaBanca
[EMAIL PROTECTED]


On Thu, Dec 4, 2008 at 1:10 PM, Joel Webber <[EMAIL PROTECTED]> wrote:

> There is already a static Event.addEventPreview() that delegates through to
> DOM.addEventPreview() (the idea being that the static DOM methods could be
> removed eventually). The static event triggering methods are also going on
> Event and following this pattern.
> +1, btw, to this whole idea. The EventPreview stuff was really built to
> support modal dialogs, and it would be very useful to generalize it in the
> way you propose.
>
>
> On Wed, Dec 3, 2008 at 4:48 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>  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
-~----------~----~----~----~------~----~------~--~---

Attachment: NativePreviewEvent.patch
Description: Binary data

Reply via email to