I completely agree that it is important to find a better solution to the irritating cross-browser differences in keyboard event handling, and I'd really like to discuss that on a separate thread (starting such a thread right now would be perfectly fine by me -- I just don't want to confuse the issue by discussing too many things on one thread). The goal of this design is to simplify and normalize the way that widget-level events are structured. So we could really use feedback on the way that events are registered and handled, the mechanism for storing and firing sets of listeners, and the way in which new widgets use them. We're planning on moving everything to this structure (with shims for backwards-compatibility), so again your feedback would be helpful.
Thanks, joel. On Tue, Sep 23, 2008 at 2:22 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > Yep, this would be a nice utility to have available, I think we might be > able to get the isControlKey() part fully integrated with the native events, > as I think we've already started down that route. > > I also like the idea of a logical key event that is only fired at sane > times if you have the bandwidth to brain storm on how to tweak your design > to get it there. We could, for instance have a static > FilterKeyEvent.fireEvent method that widgets could call which create > FilterKeyEvent's at the right time. > > > > On Tue, Sep 23, 2008 at 12:51 AM, Ian Petersen <[EMAIL PROTECTED]> wrote: > >> >> On Mon, Sep 22, 2008 at 7:43 PM, Thomas Broyer <[EMAIL PROTECTED]> >> wrote: >> > LGTM but... >> > >> > ...have the keyDown/keyUp vs. keyPress been revised? (keyPress is >> > supposed to receive "characters" while keyDown/keyUp are "keys" –this >> > is the same as TextEvent vs. KeyboardEvent in DOM Level 3 Events–, see >> > also PPK's compatibility tables). >> > In the mean time, handling keys lead to some browser-specific tweaks >> > in your own code, whereas you would expect GWT to workaround those >> > differences/bugs for you and give you a predictable behavior. >> > >> > >> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-TextEvents-Interfaces >> > http://www.quirksmode.org/dom/events/index.html#t09 >> > http://www.quirksmode.org/dom/w3c_events.html#keyprops >> > >> > See also: >> > http://code.google.com/p/google-web-toolkit/issues/detail?id=72 >> > http://code.google.com/p/google-web-toolkit/issues/detail?id=78 >> > >> > It would however affect issue 1566: >> > http://code.google.com/p/google-web-toolkit/issues/detail?id=1566 >> > (just remove the ONKEYPRESS handling, but Opera doesn't repeat keydown >> > events; this could be worked around specifically for Opera with a >> > timer to synthetize keydown events until you receive a corresponding >> > keyup event) >> >> I haven't been following too closely, so sorry if this is spam, but >> issue 1061 might be relevant, too. I haven't looked at the related >> code in quite a while, but I could always revisit it if necessary. >> http://code.google.com/p/google-web-toolkit/issues/detail?id=1061 >> >> Ian >> >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
