There is code that transforms the presumably latin-1 key value into approximately MacRoman encoding in platforms/win32/vm/sqWin32Window.c
I let the archeologists debate if this code dates from Jurassic period or more distant paleozoic era, all I know is that we pay for what we don't buy...
Thus I propose to entirely remove that piece of code and disentangle a bit the spaghetti keyboard handling.
We indeed do not need this extra level of complexity anymore, images do not use macRoman encoding for a long time
On the contrary, images have to undo the translation by sending macToSqueak
message in various subclasses of KeyboardInputInterpreter
.
For the transition period, old images running on new VMs, or new images running on old VMs, might encounter a few hickups while interpreting non ASCII characters in case of exotic KeyboardInputInterpreter
. That won't be the case of main UTF32InputInterpreter
since it mostly uses the utf32 code passed through eventBuffer sixth
position rather than keyValue passed thru eventBuffer third
, except for some CTRL+key for which the keyValue is more-than-often < 128, and thus unaffcted by the proposed change.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.