Hi all.
I'm writing my own EventSensor class (as part of Subcanvas: http://gulik.pbwiki.com/Canvas) and I'm looking at what the VM is doing.
When I press and release key under a recent Linux VM, I get three events:
#(2 512613 53 1 8 0 0 0) #(2 512613 53 0 8 0 0 0) #(2 512664 53 2 8 0 0 0)
The fields are (for those that don't already know this):
1: type (2=keyboard), 2: timestamp, 3: character in Mac Roman encoding, 4: key press/release (0=character, 1=press, 2=release) 5: modifiers (1=shift, 2=ctrl, 4=mac option, 8=cmd/alt)
and the rest of the fields are unused afaict.
Now, why do I get both a key pressed event and a character event? The key pressed event already has the character information. Is there a circumstance where these two events would differ in anything other than the type of event?
The VM doesn't send any events for only a shift/ctrl/alt key press or release. Should it?
If you hold down a key, you get a stream of key press and character events for the same key. Should it? I'd prefer to have character repetition handled within the image so that arcade games could be implemented.
Finally, I'm lazy, so I'm going to ask this mailing list how Unicode input has been handled rather than read code. Do implementations modify the VM to send Unicode characters through as field 3 (or whatever) of the input arrays? Or do the implementations take the Mac Roman encoding from the event array, look up a keyboard mapping in the image and convert the result to the correct Unicode character?
Gulik.
On Wed, Jun 24, 2009 at 2:06 PM, Michael van der Gulik mikevdg@gmail.comwrote:
Hi all.
I'm writing my own EventSensor class (as part of Subcanvas: http://gulik.pbwiki.com/Canvas) and I'm looking at what the VM is doing.
When I press and release key under a recent Linux VM, I get three events:
#(2 512613 53 1 8 0 0 0) #(2 512613 53 0 8 0 0 0) #(2 512664 53 2 8 0 0 0)
The fields are (for those that don't already know this):
1: type (2=keyboard), 2: timestamp, 3: character in Mac Roman encoding, 4: key press/release (0=character, 1=press, 2=release) 5: modifiers (1=shift, 2=ctrl, 4=mac option, 8=cmd/alt)
On a random Windows VM I just found, I get even more interesting results:
#(2 14856453 72 1 0 72 0 0) #(2 14856453 104 0 0 104 0 0) #(2 14856500 72 2 0 72 0 0)
The character changes. I typed in a lower case 'h', but the VM returns an upper-case 'H' (72) as the press and release field character, and a lower case 'h' (104) in the character field.
Why?
And why is the character repeated in the 6th field?
Also, under the Windows VM, modifier key pressed and releases /are/ sent to the VM.
Gulik.
Michael van der Gulik wrote:
On a random Windows VM I just found, I get even more interesting results:
#(2 14856453 72 1 0 72 0 0) #(2 14856453 104 0 0 104 0 0) #(2 14856500 72 2 0 72 0 0)
The character changes. I typed in a lower case 'h', but the VM returns an upper-case 'H' (72) as the press and release field character, and a lower case 'h' (104) in the character field.
Why?
Look at your keyboard. Real close. What does the letter that is printed on the keyboard say? Does it say "h" or does it say "H"? ;-)
When you press the "H" key (as it is denoted on your keyboard) the VM reports this as the "H" key which is then interpreted by Windows to be the lowercase "h" character, which it reports as well. Similarly, if you would press Shift-H, it would report that you pressed the shift key, the "H" key which then resulted in the uppercase "H" character. Makes sort of sense dunnit? ;-)
And why is the character repeated in the 6th field?
Because the Windows VM is fully Unicode capable and produces both MacRoman as well as UTF-32 for maximum compatibility.
Also, under the Windows VM, modifier key pressed and releases /are/ sent to the VM.
Yes, indeed. You are pressing that shift key, no? Why would the VM not report that? Might as well decide not to report the Q key ;-)
Cheers, - Andreas
On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab andreas.raab@gmx.de wrote:
When you press the "H" key (as it is denoted on your keyboard) the VM reports this as the "H" key which is then interpreted by Windows to be the lowercase "h" character, which it reports as well. Similarly, if you would press Shift-H, it would report that you pressed the shift key, the "H" key which then resulted in the uppercase "H" character. Makes sort of sense dunnit? ;-)
The Linux VM gives the lower-case version. I'm guessing this is a bug.
And why is the character repeated in the 6th field?
Because the Windows VM is fully Unicode capable and produces both MacRoman as well as UTF-32 for maximum compatibility.
I just tried this. The results are very interesting. Already having UTF-32 coming in from the VM certainly saves me a lot of work.
I'll see if I can find an Asian Squeak image somewhere and see how it handles input. From what I read on Wikipedia, some input methods use a small GUI widget to aid with input.
(http://en.wikipedia.org/wiki/Input_method)
Also, under the Windows VM, modifier key pressed and releases /are/ sent
to the VM.
Yes, indeed. You are pressing that shift key, no? Why would the VM not report that? Might as well decide not to report the Q key ;-)
What I meant here was that the Linux VM does not send the modifier key events at all, and then I discovered that the Windows VM does. Again, I assume this is a bug.
Gulik.
On 24.06.2009, at 07:04, Michael van der Gulik wrote:
On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab andreas.raab@gmx.de wrote:
When you press the "H" key (as it is denoted on your keyboard) the VM reports this as the "H" key which is then interpreted by Windows to be the lowercase "h" character, which it reports as well. Similarly, if you would press Shift-H, it would report that you pressed the shift key, the "H" key which then resulted in the uppercase "H" character. Makes sort of sense dunnit? ;-)
The Linux VM gives the lower-case version. I'm guessing this is a bug.
Yes and no. Truth is each VM is different. On Win you get key codes that match ASCII, on the Mac you get Apple key codes, and on Unix it's not a raw value at all (should be X11 key syms but that hass never been implemented). So you have to deal with platform dependencies anyway.
I just tried this. The results are very interesting. Already having UTF-32 coming in from the VM certainly saves me a lot of work.
I'll see if I can find an Asian Squeak image somewhere and see how it handles input. From what I read on Wikipedia, some input methods use a small GUI widget to aid with input.
The Linux VM supports XIM, as does the Etoys image.
What I meant here was that the Linux VM does not send the modifier key events at all, and then I discovered that the Windows VM does. Again, I assume this is a bug.
It is, but nobody cared enough until now.
- Bert -
There are a Windows API functions, which can be helpful for handling a keyboard input almost independetly from windows messaging implementation.
There are two useful function, which, when use the wisely could replace the keyboard input handling: GetKeyboardState - fills an array with each key state (down/up + swither on / swithed off)
MapVirtualKey - this function maps between key code <==> virtual key
so, you can implement a keyboard repeat in image, while in VM, generate only keydown/keyup events.
2009/6/24 Andreas Raab andreas.raab@gmx.de:
Michael van der Gulik wrote:
On a random Windows VM I just found, I get even more interesting results:
#(2 14856453 72 1 0 72 0 0) #(2 14856453 104 0 0 104 0 0) #(2 14856500 72 2 0 72 0 0)
The character changes. I typed in a lower case 'h', but the VM returns an upper-case 'H' (72) as the press and release field character, and a lower case 'h' (104) in the character field.
Why?
Look at your keyboard. Real close. What does the letter that is printed on the keyboard say? Does it say "h" or does it say "H"? ;-)
When you press the "H" key (as it is denoted on your keyboard) the VM reports this as the "H" key which is then interpreted by Windows to be the lowercase "h" character, which it reports as well. Similarly, if you would press Shift-H, it would report that you pressed the shift key, the "H" key which then resulted in the uppercase "H" character. Makes sort of sense dunnit? ;-)
And why is the character repeated in the 6th field?
Because the Windows VM is fully Unicode capable and produces both MacRoman as well as UTF-32 for maximum compatibility.
Also, under the Windows VM, modifier key pressed and releases /are/ sent to the VM.
Yes, indeed. You are pressing that shift key, no? Why would the VM not report that? Might as well decide not to report the Q key ;-)
Cheers, - Andreas
Everything you want to know is documented here http://isqueak.org/ioGetNextEvent
but I might have missed something or things have changed since last fall
On Tuesday, June 23, 2009, Michael van der Gulik mikevdg@gmail.com wrote:
Hi all.
I'm writing my own EventSensor class (as part of Subcanvas: http://gulik.pbwiki.com/Canvas) and I'm looking at what the VM is doing.
When I press and release key under a recent Linux VM, I get three events:
#(2 512613 53 1 8 0 0 0) #(2 512613 53 0 8 0 0 0) #(2 512664 53 2 8 0 0 0) The fields are (for those that don't already know this):
1: type (2=keyboard), 2: timestamp, 3: character in Mac Roman encoding, 4: key press/release (0=character, 1=press, 2=release) 5: modifiers (1=shift, 2=ctrl, 4=mac option, 8=cmd/alt)
and the rest of the fields are unused afaict.
Now, why do I get both a key pressed event and a character event? The key pressed event already has the character information. Is there a circumstance where these two events would differ in anything other than the type of event?
The VM doesn't send any events for only a shift/ctrl/alt key press or release. Should it?
If you hold down a key, you get a stream of key press and character events for the same key. Should it? I'd prefer to have character repetition handled within the image so that arcade games could be implemented.
Finally, I'm lazy, so I'm going to ask this mailing list how Unicode input has been handled rather than read code. Do implementations modify the VM to send Unicode characters through as field 3 (or whatever) of the input arrays? Or do the implementations take the Mac Roman encoding from the event array, look up a keyboard mapping in the image and convert the result to the correct Unicode character?
Gulik.
On Wed, Jun 24, 2009 at 3:06 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Everything you want to know is documented here http://isqueak.org/ioGetNextEvent
but I might have missed something or things have changed since last fall
Thanks, John. That is awesome.
Gulik.
On 24.06.2009, at 05:06, John McIntosh wrote:
Everything you want to know is documented here http://isqueak.org/ioGetNextEvent
but I might have missed something or things have changed since last fall
Yes, after a lot of tweaking, Unicode keyboard stroke events are believed to work fine in the Unix VM now.
- Bert -
Bert Freudenberg wrote:
On 24.06.2009, at 05:06, John McIntosh wrote:
Everything you want to know is documented here http://isqueak.org/ioGetNextEvent
but I might have missed something or things have changed since last fall
Yes, after a lot of tweaking, Unicode keyboard stroke events are believed to work fine in the Unix VM now.
Unless you have a composing keyboard, which gives you really interesting event sequences...
Michael
Here the topic which completely covers all the differences of keyboard keys mapping on 3 main OSes
http://classicteck.com/rbarticles/mackeyboard.php
if we extract the data from there, we can add this information to events (in keyboard event record there are unused slots) so, then at image side we can translate the key presses completely without dependency from OS. I mean, you can make 'A' key work as 'shift' key etc :)
P.S. Of someone of you had luck working on Yamaha PCs , especially on Yahama 2 - with slim keyboard!! This was a best keyboard i ever seen since late of 1980's . Only last 5 years a PC market producing a similar keyboards with touch & feel. Concerning technical decision, how they made a keyboards: - there was a memory region (or io ports region - don't remember exactly), which on read, gives you a bit map, which shows what keys are currently held down (with 1's ) and what is not (with 0's). There was no difference how much keys you press down - all of them is reported in this key bitfield. In contrast, on PCs there was some defective (by design) keyboards, which can't handle more than 4 keys pressed. This was especially annoying , when you playing a Mortal Combat with friend in a hot seat (both have to hold multiple keys) - if you hold down more than a 4 keys, keyboard starts beeping and ignoring input. And one of players starts losing , because can't control his character. Not very fun gameplay :)
In contrast, on Yamaha (years before PC's swallowed the market), all keys, no matter how many of them is held down is reported & handled. There also, was a different keyboard repeat handling (which i REALLY miss on PC): If you first press 'a', and hold it down, then press 'b' and hold it too, after delay, it starts repeating these keys in same sequence as you pressed them: abababab
so, without any software , which supports text formatting/macros/other helpers, you can format your code just using keyboard. For instance, if you want to indent multiple lines of text, you can quickly press and hold following keys: - tab - down arrow - home
and obviously, if you repeat the keystrokes in such order, your text will start indenting untill you think its enough. There were many possible combinations, which you will never have a chance to repeat on PC's , even if you have an uber-text-macro helpers :) Such a little difference - but such huge usability effect.
2009/6/25 Michael Rueger m.rueger@acm.org:
Bert Freudenberg wrote:
On 24.06.2009, at 05:06, John McIntosh wrote:
Everything you want to know is documented here http://isqueak.org/ioGetNextEvent
but I might have missed something or things have changed since last fall
Yes, after a lot of tweaking, Unicode keyboard stroke events are believed to work fine in the Unix VM now.
Unless you have a composing keyboard, which gives you really interesting event sequences...
Michael
[BTW, I think this discussion is more appropriate for vm-dev]
Michael van der Gulik wrote:
The fields are (for those that don't already know this):
1: type (2=keyboard), 2: timestamp, 3: character in Mac Roman encoding, 4: key press/release (0=character, 1=press, 2=release) 5: modifiers (1=shift, 2=ctrl, 4=mac option, 8=cmd/alt)
and the rest of the fields are unused afaict.
http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Cross/vm/sq.h
/* keyboard input event */ typedef struct sqKeyboardEvent { int type; /* EventTypeKeyboard */ unsigned int timeStamp; /* time stamp */ int charCode; /* character code in Mac Roman encoding */ int pressCode; /* press code; any of EventKeyXXX */ int modifiers; /* combination of xxxKeyBit */ int utf32Code; /* UTF-32 unicode value */ int reserved1; /* reserved for future use */ int windowIndex; /* host window structure */ } sqKeyboardEvent;
Now, why do I get both a key pressed event and a character event? The key pressed event already has the character information. Is there a circumstance where these two events would differ in anything other than the type of event?
Yes. Whenever you have key combinations like dead keys you will see multiple key down events and only one corresponding character event. At least that's the idea I don't know how far the Unix VM implements it.
Basically the rule is: You should get a keyDown/keyUp event for every physical key you press/release on your keyboard, be that a letter key, a a navigation key, a composition key, or a meta or function key. A keyStroke event is generated for any combinations of keys that produce actual characters.
(BTW, this rule implies that the generation of character events for navigation keys (arrow key, home/end, function keys) is incorrect)
The VM doesn't send any events for only a shift/ctrl/alt key press or release. Should it?
Yes. It's a key you are pressing. If it can generate an event it should do so.
If you hold down a key, you get a stream of key press and character events for the same key. Should it? I'd prefer to have character repetition handled within the image so that arcade games could be implemented.
It's difficult to properly map this to the (dynamic) auto key repeat frequency. So I think it should do it, yes.
Finally, I'm lazy, so I'm going to ask this mailing list how Unicode input has been handled rather than read code. Do implementations modify the VM to send Unicode characters through as field 3 (or whatever) of the input arrays? Or do the implementations take the Mac Roman encoding from the event array, look up a keyboard mapping in the image and convert the result to the correct Unicode character?
See above. It's reported as utf32 in the event.
Cheers, - Andreas
On 24.06.2009, at 06:46, Andreas Raab wrote:
If you hold down a key, you get a stream of key press and character events for the same key. Should it? I'd prefer to have character repetition handled within the image so that arcade games could be implemented.
It's difficult to properly map this to the (dynamic) auto key repeat frequency. So I think it should do it, yes.
Indeed. The convention we agreed upon for auto-repeat is that you get a key-down event when you press the key, and then more key-down events for the repeats the system generates, followed by a single key-up when the key is physically released.
I'm not sure each VM follows this convention yet.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Igor Stasenko -
John McIntosh -
Michael Rueger -
Michael van der Gulik