Rob -- 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. On May 29, 1:01 pm, Robert Hanson <iamroberthan...@gmail.com> wrote: > I was trying to implement the File API using GWT's events, and I came > 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... > > 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 theDomEvent'ssinking > "extensibility" and issue 3619. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
