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