There is code that transforms the presumably latin-1 key value into approximately MacRoman encoding in platforms/win32/vm/sqWin32Window.c 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 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 — |
> On Jun 11, 2019, at 5:04 AM, Nicolas Cellier <[hidden email]> 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 — |
In reply to this post by David T Lewis
Closed #401. — |
In reply to this post by David T Lewis
Work has been marged in 40c0390 — |
Free forum by Nabble | Edit this page |