[OpenSmalltalk/opensmalltalk-vm] Remove macRoman translation of keyboard keyValue in Win32 VM (#401)
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.
On Jun 11, 2019, at 5:04 AM, Nicolas Cellier notifications@github.com wrote:
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.
+1
Closed #401.
Work has been marged in 40c03900d2483032a6e8f0844169c11e0bb58842
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Nicolas Cellier