Please try out | Cross-platform mapping for virtual key codes :-)

Am 27.04.2021 16:40:56 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

Please find attached a changeset that adds mapping tables for virtual keys (or scan codes) for macOS, X11, and Windows. You can find them in EventSensor class >> #virtualKeysOn*

You can try out if they work through the KeyboardExerciser. Please take a look at the balloon text (i.e. tool tip) to better understand the data.

There is also a new preference:

[x] Simplify Virtual-key codes

... because of Windows who dares to couple codes to the input language (e.g. US vs. DE), which Squeak knows nothing about. macOS is better in this regard. :-)

Biggest mess is on Linux/X11. For key-down/up events, the Linux VM delivers actual character codes instead of scan codes, which makes a basic mapping to physical keys almost impossible. See EventSensor class >> #virtualKeysOnX11. We MUST fix that! Please. Somebody. Can I haz scan codes? ^__^

***

***

The good news: KeyboardEvent >> #key (and UserInputEvent >> #modifiers) now gives you cross-platform stable information about physical keys to be used in keyboard handlers. Yes, for both key-stroke and key-down/up events.

Or at least, that is the plan. That's why it would be great if you could help testing! :-)

Why key-stroke events too? Aren't they for typing text only?

1. Almost all keyboard shortcuts in current Squeak are based on key-stroke events.

2. Using the #keyCharacter is tricky because SHIFT changes lower-case to upper-case, which makes "anEvent shiftPressed" hard to understand.

3. CTRL combinations might not do the expected thing. How would you handle CTRL+C? The #keyCharacter could arrive as $c or Character enter. See the preference "Map non-printable characters to printable characters. Now, #key will always answer $C in such a case. Regardless of that preference.

Can't we just use #keyCharacter in key-down/up events?

No. Those are undefined. Never do that. key-down/up events carry virtual-key codes in their #keyValue. We might want to change #keyCharacter to answer "nil" for those events.

***

Q: What is a "physical key" or "physical modifier"?

A: The label that can be presented to the user so that he or she feels at home when using Squeak. Thus, looks platform-specific.

Q: What is a "virtual key" or "virtual modifier"?

A: The information to be processed in your application's key handlers. Thus, looks platform-independent. If you have still no clue how to talk to keyboard events, please read the commentary in KeyboardEvent >> #checkCommandKey.

***

Happy testing! :-) And thank you all in advance!

Best,

Marcel

P.S.: You might want to disable the preference "synthesize mouse-wheel events from keyboard-events" to get CTRL+ArrowUp and CTRL+ArrowDown ;-)

Am 01.05.2021 19:51:04 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

following observations for your first question:

• Key strokes for characters such as $+, $#, $ß, $?, or $- yield "Squeak1" or "Squeak2" in my image.
• Combinations such as "dead circumflex , space" that print a $^ on my Qwertz system are displayed as pure "space" in the tool.
• Ctrl + Alt + E (types $€), Ctrl + Alt + 7 (types ${), Alt + (NumPlus , Num2, Num0) (types $ ), etc. are printed as "E", "7", "0", etc. only.

Regarding your remaining questions, I cannot really add much value to this because I have never dealt with this before. But there weren't any WTF moments. :-)

What about different keyboard layouts such as QWERTZ/QWERTY/AWERTY etc.? What about virtual ways to enter characters (e.g. tools for special characters, emojipads, etc.). How do you make sure that these virtual keys are mapped correctly to their physical equivalents?

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 28. April 2021 12:02 Uhr
An: squeak-dev
Betreff: Re: [squeak-dev] Please try out | Cross-platform mapping for virtual key codes :-)

 

Hi all!

Here is a small update. Please find attached the changeset.

Updates:

- Adds KeyboardEvent >> #keyCode (via new inst-var)

- Logs the last key-down event to attach virtual-key codes to key-stroke events; see HandMorph >> #generateKeyboardEvent:

- Simplifies KeyboardEvent >> #key

- Show event repetition in KeyboardExecizer

Major questions:

1. Does it work on your machine?

2. What are your thoughts on KeyboardEvent >> #key?

3. What are your thoughts on KeyboardEvent >> #keyCode?

4. Do you understand KeyboardEvent >> #physicalKey #virtualKey #physicalModifiers #virtualModifiers ?

Happy testing!

Best,

Marcel

P.S.: Don't forget about the X11 key (scan?) codes. ^__^ I haven't had the time to look into the VM plugin yet.

Am 27.04.2021 16:40:56 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

Please find attached a changeset that adds mapping tables for virtual keys (or scan codes) for macOS, X11, and Windows. You can find them in EventSensor class >> #virtualKeysOn*

You can try out if they work through the KeyboardExerciser. Please take a look at the balloon text (i.e. tool tip) to better understand the data.

There is also a new preference:

[x] Simplify Virtual-key codes

... because of Windows who dares to couple codes to the input language (e.g. US vs. DE), which Squeak knows nothing about. macOS is better in this regard. :-)

Biggest mess is on Linux/X11. For key-down/up events, the Linux VM delivers actual character codes instead of scan codes, which makes a basic mapping to physical keys almost impossible. See EventSensor class >> #virtualKeysOnX11. We MUST fix that! Please. Somebody. Can I haz scan codes? ^__^

***

***

The good news: KeyboardEvent >> #key (and UserInputEvent >> #modifiers) now gives you cross-platform stable information about physical keys to be used in keyboard handlers. Yes, for both key-stroke and key-down/up events.

Or at least, that is the plan. That's why it would be great if you could help testing! :-)

Why key-stroke events too? Aren't they for typing text only?

1. Almost all keyboard shortcuts in current Squeak are based on key-stroke events.

2. Using the #keyCharacter is tricky because SHIFT changes lower-case to upper-case, which makes "anEvent shiftPressed" hard to understand.

3. CTRL combinations might not do the expected thing. How would you handle CTRL+C? The #keyCharacter could arrive as $c or Character enter. See the preference "Map non-printable characters to printable characters. Now, #key will always answer $C in such a case. Regardless of that preference.

Can't we just use #keyCharacter in key-down/up events?

No. Those are undefined. Never do that. key-down/up events carry virtual-key codes in their #keyValue. We might want to change #keyCharacter to answer "nil" for those events.

***

Q: What is a "physical key" or "physical modifier"?

A: The label that can be presented to the user so that he or she feels at home when using Squeak. Thus, looks platform-specific.

Q: What is a "virtual key" or "virtual modifier"?

A: The information to be processed in your application's key handlers. Thus, looks platform-independent. If you have still no clue how to talk to keyboard events, please read the commentary in KeyboardEvent >> #checkCommandKey.

***

Happy testing! :-) And thank you all in advance!

Best,

Marcel

P.S.: You might want to disable the preference "synthesize mouse-wheel events from keyboard-events" to get CTRL+ArrowUp and CTRL+ArrowDown ;-)

Am 03.05.2021 10:59:16 schrieb Marcel Taeumel <[hidden email]>:

Hi Christoph,

thanks for your thoughts. There might be a need for some clarification, especially the difference between "key character" and "(virtual) key".

First of all, the visuals of the KeyboardExerciser do not match writing tools but physical keyboards. While you can explore the input event and take a look at #keyCharacter, I suggest you use a workspace to try whether you can still type and write characters as you need.

Second, dead keys such as the circumflex mainly affect #keyCharacter because they should help you type characters in your writing tool. Regarding physical keys and their presses, dead keys are rather inconvenient. You would have to press them twice to register a single key-down event.

Now back to the virtual keys and key codes.

You raised the question about different keyboard layouts. At best, the operating system would abstract virtual-key codes (i.e. keyboard layout) from input language (e.g. US, DE). So, on QWERTZ with DE, you will get key-code for Q, W, E, R, T, Z and on QWERTY with US you get ... Y. 

If you lie about your physical layout for more convenient typing, it becomes tricky. The user is not aware of the labels on the physical keys but relies on the virtual abstraction. So, pressing the key labeled "Z" while thinking about Y and then getting the key-code for Z might be surprising. That's why Windows relies on the user to tell which kind of keyboard she has attached. After wall, the operating system does not use a camera to check the physical world itself. Hehe.

At the end of the day, we have to rely on the user telling the truth to the operating system about the layout of the physical keyboard. Luckily, modern operating systems separate keyboard layout from input language for spelling correction etc. For example, I have QWERTZ also configured for English, not just German.

That's why DVORAK can work. You just have to tell your operating system that your keyboard has the DVORAK layout. It's nothing Squeak has to take care of.

Best,

Marcel

Am 01.05.2021 19:51:04 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

following observations for your first question:

• Key strokes for characters such as $+, $#, $ß, $?, or $- yield "Squeak1" or "Squeak2" in my image.
• Combinations such as "dead circumflex , space" that print a $^ on my Qwertz system are displayed as pure "space" in the tool.
• Ctrl + Alt + E (types $€), Ctrl + Alt + 7 (types ${), Alt + (NumPlus , Num2, Num0) (types $ ), etc. are printed as "E", "7", "0", etc. only.

Regarding your remaining questions, I cannot really add much value to this because I have never dealt with this before. But there weren't any WTF moments. :-)

What about different keyboard layouts such as QWERTZ/QWERTY/AWERTY etc.? What about virtual ways to enter characters (e.g. tools for special characters, emojipads, etc.). How do you make sure that these virtual keys are mapped correctly to their physical equivalents?

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 28. April 2021 12:02 Uhr
An: squeak-dev
Betreff: Re: [squeak-dev] Please try out | Cross-platform mapping for virtual key codes :-)

 

Hi all!

Here is a small update. Please find attached the changeset.

Updates:

- Adds KeyboardEvent >> #keyCode (via new inst-var)

- Logs the last key-down event to attach virtual-key codes to key-stroke events; see HandMorph >> #generateKeyboardEvent:

- Simplifies KeyboardEvent >> #key

- Show event repetition in KeyboardExecizer

Major questions:

1. Does it work on your machine?

2. What are your thoughts on KeyboardEvent >> #key?

3. What are your thoughts on KeyboardEvent >> #keyCode?

4. Do you understand KeyboardEvent >> #physicalKey #virtualKey #physicalModifiers #virtualModifiers ?

Happy testing!

Best,

Marcel

P.S.: Don't forget about the X11 key (scan?) codes. ^__^ I haven't had the time to look into the VM plugin yet.

Am 27.04.2021 16:40:56 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

Please find attached a changeset that adds mapping tables for virtual keys (or scan codes) for macOS, X11, and Windows. You can find them in EventSensor class >> #virtualKeysOn*

You can try out if they work through the KeyboardExerciser. Please take a look at the balloon text (i.e. tool tip) to better understand the data.

There is also a new preference:

[x] Simplify Virtual-key codes

... because of Windows who dares to couple codes to the input language (e.g. US vs. DE), which Squeak knows nothing about. macOS is better in this regard. :-)

Biggest mess is on Linux/X11. For key-down/up events, the Linux VM delivers actual character codes instead of scan codes, which makes a basic mapping to physical keys almost impossible. See EventSensor class >> #virtualKeysOnX11. We MUST fix that! Please. Somebody. Can I haz scan codes? ^__^

***

***

The good news: KeyboardEvent >> #key (and UserInputEvent >> #modifiers) now gives you cross-platform stable information about physical keys to be used in keyboard handlers. Yes, for both key-stroke and key-down/up events.

Or at least, that is the plan. That's why it would be great if you could help testing! :-)

Why key-stroke events too? Aren't they for typing text only?

1. Almost all keyboard shortcuts in current Squeak are based on key-stroke events.

2. Using the #keyCharacter is tricky because SHIFT changes lower-case to upper-case, which makes "anEvent shiftPressed" hard to understand.

3. CTRL combinations might not do the expected thing. How would you handle CTRL+C? The #keyCharacter could arrive as $c or Character enter. See the preference "Map non-printable characters to printable characters. Now, #key will always answer $C in such a case. Regardless of that preference.

Can't we just use #keyCharacter in key-down/up events?

No. Those are undefined. Never do that. key-down/up events carry virtual-key codes in their #keyValue. We might want to change #keyCharacter to answer "nil" for those events.

***

Q: What is a "physical key" or "physical modifier"?

A: The label that can be presented to the user so that he or she feels at home when using Squeak. Thus, looks platform-specific.

Q: What is a "virtual key" or "virtual modifier"?

A: The information to be processed in your application's key handlers. Thus, looks platform-independent. If you have still no clue how to talk to keyboard events, please read the commentary in KeyboardEvent >> #checkCommandKey.

***

Happy testing! :-) And thank you all in advance!

Best,

Marcel

P.S.: You might want to disable the preference "synthesize mouse-wheel events from keyboard-events" to get CTRL+ArrowUp and CTRL+ArrowDown ;-)

...
recordKeyboardEvent(0, EventKeyDown, modifierState, utf32);
recordKeyboardEvent(0, EventKeyChar, modifierState, utf32);
...

Am 15.05.2021 17:17:18 schrieb David T. Lewis <[hidden email]>:

Hi Marcel,

Attached are changes that should make the virtual key mapping work
when the image is restarted on a different platform.

Dave


On Wed, Apr 28, 2021 at 12:02:44PM +0200, Marcel Taeumel wrote:

> Hi all!
>
> Here is a small update. Please find attached the changeset.
>
> Updates:
> - Adds KeyboardEvent >> #keyCode (via new inst-var)
> - Logs the last key-down event to attach virtual-key codes to key-stroke events; see HandMorph >> #generateKeyboardEvent:
> - Simplifies KeyboardEvent >> #key
> - Show event repetition in KeyboardExecizer
>
>
>
> Major questions:
> 1. Does it work on your machine?
> 2. What are your thoughts on KeyboardEvent >> #key?
> 3. What are your thoughts on KeyboardEvent >> #keyCode?
> 4. Do you understand KeyboardEvent >> #physicalKey #virtualKey #physicalModifiers #virtualModifiers ?
>
> Happy testing!
>
> Best,
> Marcel
>
> P.S.: Don't forget about the X11 key (scan?) codes. ^__^ I haven't had the time to look into the VM plugin yet.
> Am 27.04.2021 16:40:56 schrieb Marcel Taeumel :
> Hi all!
>
>
> Please find attached a changeset that adds mapping tables for virtual keys (or scan codes) for macOS, X11, and Windows. You can find them in EventSensor class >> #virtualKeysOn*
>
> You can try out if they work through the KeyboardExerciser. Please take a look at the balloon text (i.e. tool tip) to better understand the data.
>
> There is also a new preference:
> [x] Simplify Virtual-key codes
>
> ... because of Windows who dares to couple codes to the input language (e.g. US vs. DE), which Squeak knows nothing about. macOS is better in this regard. :-)
>
> Biggest mess is on Linux/X11. For key-down/up events, the Linux VM delivers actual character codes instead of scan codes, which makes a basic mapping to physical keys almost impossible. See EventSensor class >> #virtualKeysOnX11. We MUST fix that! Please. Somebody. Can I haz scan codes? ^__^
>
> ***
>
>
> ***
>
> The good news: KeyboardEvent >> #key (and UserInputEvent >> #modifiers) now gives you cross-platform stable information about physical keys to be used in keyboard handlers. Yes, for both key-stroke and key-down/up events.
>
> Or at least, that is the plan. That's why it would be great if you could help testing! :-)
>
> Why key-stroke events too? Aren't they for typing text only?
>
> 1. Almost all keyboard shortcuts in current Squeak are based on key-stroke events.
> 2. Using the #keyCharacter is tricky because SHIFT changes lower-case to upper-case, which makes "anEvent shiftPressed" hard to understand.
> 3. CTRL combinations might not do the expected thing. How would you handle CTRL+C? The #keyCharacter could arrive as $c or Character enter. See the preference "Map non-printable characters to printable characters. Now, #key will always answer $C in such a case. Regardless of that preference.
>
> Can't we just use #keyCharacter in key-down/up events?
>
> No. Those are undefined. Never do that. key-down/up events carry virtual-key codes in their #keyValue. We might want to change #keyCharacter to answer "nil" for those events.
>
> ***
>
> Q: What is a "physical key" or "physical modifier"?
> A: The label that can be presented to the user so that he or she feels at home when using Squeak. Thus, looks platform-specific.
>
> Q: What is a "virtual key" or "virtual modifier"?
> A: The information to be processed in your application's key handlers. Thus, looks platform-independent. If you have still no clue how to talk to keyboard events, please read the commentary in KeyboardEvent >> #checkCommandKey.
>
> ***
>
> Happy testing! :-) And thank you all in advance!
>
> Best,
> Marcel
>
> P.S.: You might want to disable the preference "synthesize mouse-wheel events from keyboard-events" to get CTRL+ArrowUp and CTRL+ArrowDown ;-)

>