Note: linux behavior is not strange, it is deliberate, see this: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a4a08f98c17b23ad54b5e...

It was introduced with https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1b837f94e96b93cb4d1...

If we want to fix it, we can just enclose this piece of code with `#ifdef PharoVM`, as it is already the case for similar code on windows: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a4a08f98c17b23ad54b5e...

Though, on windows, only the `utf32` field (`event at: 6`) is changed, while on linux `charCode` field (`event at: 3`) is also changed.

I do not see equivalent code on OSX...

However, I suggest deeper change, as in this branch: https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Nuke-MacRoman

We should have `charCode` transformed into a platform independent `keyCode`, hence not being an ASCII control character, but rather a letter in case of Ctrl+a. (X11 KeySym and windows Virtual Key codes already match ASCII for keys representing ASCII characters).

Then the utf32 can eventually be the ASCII control character or not, whatever we want, we have to decide...

Hi Nicolas,

I'm following the discussion on the background. I think you're right on using the keycode and not an ascii code. Using ascii to identify keys is a vestige from old "silly terminals". However, there are no keys in ascii to identify for example keys like ctrl, cmd or alt by themselves (and not as modifiers).

Regarding keyboard events (dunno about mousewheel in particular), my take here is that existing windowing/ui frameworks (cocoa/carbon, x11, windows forms..) send two different kind of events: - key up / key down => identify wether a key is pressed or released with key code, no text is available. Here we can catch single ctrl/alt/cmd/F[X]/etc presses. - a text event (which we call key press ourselves, maybe misleading) which sends text in some encoding as soon as it is available + associated modifiers

Now, the complication here to me is that historically morphic (in squeak and pharo, probably cuis still too?) has been using the text event to drive everything, even shortcuts. So the code managing keyup/downs is not used at all in my experience, and the code managing keypresses in morphs is overly complicated. And changing this while changing the VM at the same time can lead easily to a state where we cannot type :).

Now, as a single small step in what I believe is the right direction, I've implemented in Pharo mappings of keyboard virtual tables => the VM sends the raw virtual keycode to the image side (which depends on the platform) and on the image side this platform dependent virtual keycode is mapped to a common representation for all of them. Like that a single virtual key code table is used in client code. When I did that a couple of years ago, I've chosen to use "in image" X11's virtual key codes because it looked the broader and it seemed to contain the ones from osx and windows. Check https://github.com/pharo-project/pharo/blob/Pharo8.0/src/System-Platforms/Ke....

Then the idea is that morphic events are extended to get the correct key object with a double dispatch:

```smalltalk KeyboardEvent >> key ^Smalltalk os keyForValue: keyValue

UnixPlatform >> keyForValue: aKeyValue ^KeyboardKey valueForUnixPlatform: aKeyValue. ```

Still missing, some accessors for common keys like `KeyboardKey f11` `KeyboardKey ctrl`, which would allow for code like the following to open/close a morph while a key is being pressed (without an active wait ;)).

```smalltalk MyMorph>>keyDown: anEvent anEvent key = KeyboardKey alt ifTrue: [ self openWindowSelector ]

MyMorph>>keyUp: anEvent anEvent key = KeyboardKey alt ifTrue: [ self closeWindowSelector ] ```

A similar approach could be implemented vm side to map events. I like however the image one because it can be changed easily :)

Hi Guile, I think that we can find an agreement. X11 KeySym looks like the best choice to me, and I would like to use that in (event at: 3). Apart the arrow, prior, next, home, end, BS, delete, insert, Escape, Tab that we already map to some ASCII control character in a platform independent manner (breaking compatibility on those might be a pain).

Note that the squeak is using `keystroke` in lower event level, and OSVM is using `EventKeyChar`, when a character is produced (not just a key pressed). Shortcuts should probably be handled at EventKeyDown like it usually is on various OSes (that's the windows recommended way). We can as well connect Morphic keyPressed: to event keydown if we want to, not too difficult.

Note that we also have unused slots (reserved1) in keyboard events, and I thought that we could use that to transfer OS dependent keyCode. This way, we could experiment both image side handling, and VM side handling of more complex events (composition etc...). Also, we would preserve a smooth transition without complete locked in syndrome.

Note that even for occidental languages, I'm not satisfied with linux handling of dead keys (^ ¨ `) at VM side, I get decomposed unicode while the image rather expect precomposed (we can change the image for simple thing like that, but it's lot more work for more complex cases like you have shown).

So IMO, OSVM should provide: - a platform independent keycode in (event at: 3) - utf32 (ucs4) character in (event at: 6) at least for EventKeyChar - a platform dependent keycode (reserved1 - to be renamed) for image side experiments There can be keydown events without corresponding keychar event. There can be several consecutive keychar events following a single keydown event. There can be keydown/keychar events without keyup event for repeated keys, and the OSVM should take repeat count of keys into account! (pass that in some unused event field too...).