Improving event handling, as initiated in 1.6
Thomas Broyer
GWT 1.6 introduced the new event handling, which is really great. It
however suffers from some limitations, the one bugging me the most
being the difficulty/impossibility to support new DomEvents, such as
D'n'D events, ononline/onoffline, onstorage, or browser-specific
events (those that can be emulated in other browsers: mouseenter/
mouseleave, focusin/focusout; and those that cannot: onhelp, onselect/
onselectionchange/onselectstart, onmozorientationchange,
ongesturestart/change/end, ontouchstart/end/move/cancel,
onorientation, etc.)
This is because event's "sinking" is done by DOMImpl using a field of
bits, instead of being baked into DomEvent (using an "Impl" class with
deferred binding by browser). How about, for instance, building it
into DomEvent::Type, so that addDomHandler could call type.sinkEvent
(xxx)?
Other improvements that I'd like to see happening re. events:
- finally accurate (not necessarily 100%-identical cross-browser-
wise) support for key/keyboard events (issues 72, 1061, 1529, and
3753, and issue 3640)
see also http://groups.google.fr/group/Google-Web-Toolkit-Contributors/t/e705905e2cc78408
- onfocus/onblur on Window (issue 68)
- focus/blur event preview (issue 1431)
- unsink events when there all handlers have been removed (issue
3619)
- allow listening to events in the capture phase instead of only
being able to listen to the bubble phase
This last issue (3619) cannot be solved without either (as I proposed
in comment #3 on the issue):
- changing Widget::addDomHandler wrap the HandlerRegistration so that
removeHandler() queues a "finally command" to eventually unsink the
event
- baking this in HandlerManager, eventually by introducing a
"DomHandlerManager extends HandlerManager" to be used by widgets
See also http://groups.google.fr/group/google-web-toolkit-contributors/msg/cd484824ba10e2dd
I volunteer to provide patches, but I need to know what you, "GWT
team", want and want-not. I'd happily work on sorting those key/
keyboard events out, followed by rework of the DomEvent's sinking
"extensibility" and issue 3619.
Robert Hanson
across this post and others. There is also an issue for this, which
was accepted, but the last comment is from 2008 (http://
code.google.com/p/google-web-toolkit/issues/detail?id=2562).
Just wondering if this is in the works (maybe already in the trunk),
or if this is on the back-burner.
Thanks.
Rob
---------- Forwarded message ----------
From: Thomas Broyer <t.bro...@gmail.com>
Date: Dec 21 2009, 8:01 pm
Subject: Improving event handling, as initiated in 1.6
To: Google Web Toolkit Contributors
Hi Googlers,
GWT 1.6 introduced the new event handling, which is really great. It
however suffers from some limitations, the one bugging me the most
being the difficulty/impossibility to support new DomEvents, such as
D'n'D events, ononline/onoffline, onstorage, or browser-specific
events (those that can be emulated in other browsers: mouseenter/
mouseleave, focusin/focusout; and those that cannot: onhelp, onselect/
onselectionchange/onselectstart, onmozorientationchange,
ongesturestart/change/end, ontouchstart/end/move/cancel,
onorientation, etc.)
This is because event's "sinking" is done by DOMImpl using a field of
bits, instead of being baked intoDomEvent(using an "Impl" class with
deferred binding by browser). How about, for instance, building it
intoDomEvent::Type, so that addDomHandler could call type.sinkEvent
(xxx)?
Other improvements that I'd like to see happening re. events:
- finally accurate (not necessarily 100%-identical cross-browser-
wise) support for key/keyboard events (issues 72, 1061, 1529, and
3753, and issue 3640)
see alsohttp://groups.google.fr/group/Google-Web-Toolkit-Contributors/t/e7059...
- onfocus/onblur on Window (issue 68)
- focus/blur event preview (issue 1431)
- unsink events when there all handlers have been removed (issue
3619)
- allow listening to events in the capture phase instead of only
being able to listen to the bubble phase
This last issue (3619) cannot be solved without either (as I proposed
in comment #3 on the issue):
- changing Widget::addDomHandler wrap the HandlerRegistration so that
removeHandler() queues a "finally command" to eventually unsink the
event
- baking this in HandlerManager, eventually by introducing a
"DomHandlerManager extends HandlerManager" to be used by widgets
See alsohttp://groups.google.fr/group/google-web-toolkit-contributors/msg/cd4...
Brendan Kenny
You might have already seen this, but Thomas created a wave on the
topic to get things moving
https://wave.google.com/wave/#restored:wave:googlewave.com!w%252Bux7zL81XA
"post I/O" seems to be the general timeframe, but I know I'm eager to
help create a more extensible system as well. Many more event types
than I know where to put these days.
Dan
access to do anything but add blank replies...
On May 31, 5:48 am, Brendan Kenny <bcke...@gmail.com> wrote:
> Rob --
>
> You might have already seen this, but Thomas created a wave on the
Thomas Broyer
> I don't suppose you could bump the wave Thomas? I seem to not have
> access to do anything but add blank replies...
I've added you to the wave. Don't know what happened as you're a
member of GWT-Contrib, which has full access to the wave...
