On Jan 26, 2012, at 7:07 PM, Guillermo Polito wrote:
> Following the Event chronicles :P
>
> Since I know that some people are working on event Stuff(Stef, Fernando,
> Igor), I'd like to listen to what they(or anybody else :) ) think about this.
> I've no code (yet) except for the one I've written to play with the vm and
> test the keyboard stuff :P. And I know there is some package where Stef and
> Igor where refactoring the event stuff and I don't want to duplicate efforts
> either, jeje.
have a look at EventModel on squeak source.
For now we did not modify the handling of keystrokes. We "just" reified event
instead of manipulating eventbuf uglies.
I'm sick now so my brain is slow.
Two points are
- transition from old to new . Is there a path with little impact on
users. I guess so.
- what about VM changes…
Stef
> So, this is what from other models I think a complete keyboard event model
> should have:
>
> Keyboard interaction raises 3 events (3 different kind of objects!):
>
> • Keydown
> When a key is pressed, it informs the pressed key with modifiers (it should
> not send a unicode value of a character).
>
> Should understand the messages:
>
> "boolean indicating which modifiers where pressed"
> #alt
> #cmd
> #shift
> #ctrl
> #opt?
>
> "a collection of modifier objects"
> #modifiers
>
> "the key pressed. It is not a Character, it should be an instance of Key
> (read about Keys in the Glitches below)"
> #key
>
> "to know if the event wasHandled"
> #handled:
> #handled
>
> • Keypress
> When a key with a unicode representation is pressed, informs it.
>
> should understand the messages:
>
> "the unicode character representation of this event. It is a Character, not
> an instance of Key"
> #character
>
> "to know if the event wasHandled"
> #handled:
> #handled
>
> • Keyup
> When a key is released, it informs the released key with modifiers (it should
> not send a unicode value of a character).
>
> Should understand the messages:
>
> "the main key pressed. It is not a Character, it should be an instance of
> Key (read about Keys in the Glitches below)"
> #key
>
> "to know if the event wasHandled"
> #handled:
> #handled
>
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Glitches
>
> 1) Today every keyboard event handled on the image side is handled on
> keypress, which:
> - limits the ammount of shortcuts you can have (because there are keys that
> you can't handle)
> - to make it work, there are some hacks (at image and vm side) to allow
> keys with no char representation enter as keypresses (like arrow keys).
> - changing this is ALOT of work :P
>
> 2) Some key representation varies from platform to platform. i.e.: A
> Shift-only press generates today a keydown event with:
> - a 254 keyCode value in unix
> - a 16 keyCode value in windows
>
> So I think a "table" has to be built and documented for mappings for each key
> in a keyboard. Examples of this can be found in enums/defs from other
> platforms:
>
> Windows platform:
> http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx
> .Net:
> http://msdn.microsoft.com/en-us/library/system.windows.forms.keys(v=vs.71).aspx
> X11 (current used window system in unix vm):
> http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h
> Javascript:
> http://www.cambiaresearch.com/articles/15/javascript-char-codes-key-codes
> Gtk: http://www.koders.com/c/fidD9E5E78FD91FE6ABDD6D3F78DA5E4A0FADE79933.aspx
>
> After that, both vm's and image should follow that table :). And of course,
> these keys should be reified in the image side independently of their
> character pairs.
>
> Guille
>
