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).as... .Net: http://msdn.microsoft.com/en-us/library/system.windows.forms.keys(v=vs.71).a... 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