On Fri, Jan 27, 2012 at 1:52 PM, Igor Stasenko <[email protected]> wrote:
> 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> > Ok, but, what if you have alt+a? You have to send 2 keycodes. And Alt+shift+r 3 keycodes. Or maybe we just send a keydown for each pressed key and handle the combinations inside the image playing with keyups and keydowns... Keydown ctrl -> ctrl pressed keydown shit -> ctrl shift pressed Keydown a -> ctrl shift a pressed keyup ctrl -> shift a pressed Keyup a -> shift pressed keyup shift -> nothing pressed > > "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? > Hmm, actually, I was modeling them as morphic events, and it has a meaning there so the event can bubble until it is handled :) > 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. > Yeap, SystemEvents and Morphic events should differ I think (one wrapping the other or not...). > > > 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. > why every time? :/ Ok, if we change the model every 2 months yes, it will be a trouble. But if we don't? How much time has passed since the last time the event stuff was touched? I think it does not happen every day... Wasn't it the vm's job to abstract these differences between platforms? Cheers, Guille
