On 26 January 2012 19:07, Guillermo Polito <[email protected]> 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. > see sqs/EventModel
> 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? > <RANT> why we can't just send a key code to image and be done with it? what if i want , in my image, for some weird reason, to use 'A' key as a 'modifier'? why at all, we need to distinguish between normal keys from 'modifier' keys, when VM and OSes are capable to generate a same events for all keys user punching? IMO, those 'modifiers' are serving for nothing, but just unnecessary increase of complexity in VM , and data structures (events) we exchanging with VM. There are 3 bits for modifiers namely , shift, alt, cmd .. so i cannot distinguish between left and right shift pressed (cool! awesome! wonderful!). Not mentioning that some laptops having a 'fn' modifier key, but who needs that, right? </RANT> > "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 > who will handle that? if even not handled, what you do next? what is purpose of it? i mean, at low level (between VM and image) you need only the way to deliver events. who handling them or what happens later is absolutely not our concern at this level. > 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 > ditto > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > 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 > yeah :) > 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 > IMO, we should deal with this at image side. It is much easier to fix code in image, than digging into VM every time we need to fix it. > 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 > right. > 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 > -- Best regards, Igor Stasenko.
