[Pharo-project] Proposed (or just written down desired) Keyboard Event Model

Igor Stasenko siguctua at gmail.com
Fri Jan 27 17:52:21 CET 2012


On 26 January 2012 19:07, Guillermo Polito <guillermopolito at gmail.com> 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.



More information about the Pharo-project mailing list