Hi Christoph.

> When pressing something like Ctrl + ArrowLeft, the keystroke event no longer answers true for #commandKeyPressed but for #optionKeyPressed instead. 

Could you be more specific? With the current default settings on Linux and Windows (see EventSensor class >> #startUp), you should get both #controlKeyPressed and #commandKeyPressed for [CTRL]+[ArrowLeft]. When you press [ALT]+[ArrowLeft], wenn you get true for #commandKeyPressed and #optionKeyPressed.

Could you understand my explanations in KeyboardEvent >> #checkCommandKey regarding cross-platform compatibility? If not, what is missing?

Best,
Marcel
Am 25.04.2021 19:59:00 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel,

great idea, thanks for your work. It works fine on Windows as well as WSL/Ubuntu/VvXsrv for all my usual workflows. :-)

I noted some "breaking change", but actually it is a fix: When pressing something like Ctrl + ArrowLeft, the keystroke event no longer answers true for #commandKeyPressed but for #optionKeyPressed instead. This makes a workaround in WindowAcrobatics [1] superfluous.

The KeyboardExerciser is also a great tool. It gives a good overview of what is still left to do for the input mapping - that is (on Windows):

* Ctrl + (Insert | Home | End | PageUp | PageDown) is mapped incorrectly to Ctrl + (A | D | L | ...)
* Ctrl + Alt + <letter> is not recorded
* Ctrl + Shift + Space is not recorded
* In my image, Shift + Alt + U does not work - is this a strange bug or do I have an unknown global keyboard filter?
[http://www.hpi.de/]

And here is some - though minor - notes about the exerciser tool:

* The "Move your mouse cursor" instruction message does not fit into the morph in my image and is not word-wrapped but misses a draw invalidation instead. Also, it is not multilanguage-safe, but since it is in the "Demo" system category, I guess this is okay. :D

Best,
Christoph

[1] https://github.com/hpi-swa-teaching/WindowAcrobatics/blob/3398eb951d674360a37fe422710340e53a69bd84/packages/WindowAcrobatics-Core.package/WAHandler.class/instance/handle..st#L5 [https://github.com/hpi-swa-teaching/WindowAcrobatics/blob/3398eb951d674360a37fe422710340e53a69bd84/packages/WindowAcrobatics-Core.package/WAHandler.class/instance/handle..st#L5]

Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Gesendet: Samstag, 24. April 2021 20:58 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Please try it out | Fixing the input mapping for keystroke events
 
Hi Marcel,
I tried it on macos and windows, no problem so far.
I had some fun with the exercizer, some combinations are surprising indeed...


Le ven. 23 avr. 2021 à 18:23, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

Hi all!

Please find attached an updated changeset with a "KeyboardExerciser" to help you test and inspect the incoming keyboard events. You can find it also in the parts bin nearby the "ClickExerciser".


The visuals are supposed to look platform-specific. However, the event data contains information to make your application work across platforms. See KeyboardEvent >> #checkCommandKey for more explanations.

Try [CTRL]+[C] for keyStroke, keyDown, and keyUp.

Note that the visuals might not look right for keyUp and keyDown events due to missing lookup tables for the raw, platform-specific key codes. On my machine, for example, [,] and [.] and [-] look odd:



Nothing to worry about because all keyboard shortcuts in Squeak use keyStroke events at the moment.

Best,
Marcel
Am 22.04.2021 10:41:15 schrieb Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]>:
Hi all!

Please find attached a changeset that improves the cross-platform base for keystroke events. Please try it out and take a look at it. Report issues ASAP so that I can merge it into Trunk soon.

Thanks to Tom (tobe), the new promising idea is to replace the existing attempt:

Duplicate all control and alt keys
Duplicate control and alt keys
Swap control and alt keys

With the following preferences:

[X] Map ASCII control characters to printable characters

 - Default is TRUE
 - Only affects events that have the CONTROL modifier set (e.g. CTRL+J)
 - Rather application-specific than platform-specific
[X] Map CONTROL keys to COMMAND keys

 - Checked at image start-up
 - TRUE on Windows/Linux
 - FALSE on macOS
[X] Map ALT keys to OPTION keys
 - Checked at image start-up
 - TRUE on Windows/Linux
 - FALSE on macOS (bc. ALT==CMD on recent Linux/Windows VMs)

Please take a look at KeyboardEvent >> #checkCommandKey to learn about the fundamental trade-off we have solved.

Please try out your preferred applications. Feel free to add logging to HandMorph >> #logEvent: for more convenient testing:

(anEvent isKeyboard and: [anEvent isKeystroke])
   ifTrue: [Transcript showln: anEvent].

Thanks!

Best,
Marcel (and Tom)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210426/a3e7a80d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 37054 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210426/a3e7a80d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9239 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210426/a3e7a80d/attachment-0003.png>