Branch: refs/heads/Nuke-MacRoman
Home:
https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: a54a2240565e729b5f613a1c2b3277bb3a8a2873
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a54a2240565e729b5f613a1c2b3277bb3a8a2873 Author: Nicolas Cellier <
[hidden email]>
Date: 2019-12-23 (Mon, 23 Dec 2019)
Changed paths:
M platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m
M platforms/iOS/vm/iPhone/Classes/SqueakUIView.m
Log Message:
-----------
Convert charCode to latin1 encoding rather than macRoman on iOS.
Why? because image side uses unicode encoding for characters, and that matches latin1 up to 256.
Once upon a time, the image side did use macRoman, so that explains the legacy code.
But such legacy has become a drag, let's get rid of it!
TODO: same changes required on legacy Mac OS
But I might apply those change after merging the compile_legacy_Mac_OS code in order to avoid potential conflicts.
Commit: cd50cd4d1b743c718651182c4809f47499e52864
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/cd50cd4d1b743c718651182c4809f47499e52864 Author: Nicolas Cellier <
[hidden email]>
Date: 2019-12-23 (Mon, 23 Dec 2019)
Changed paths:
M platforms/unix/vm/sqUnixCharConv.c
Log Message:
-----------
Let default sqTextEncoding be latin1 instead of macRoman on unix VM
sqTextEncoding is supposed to match the encoding used at image side.
Why macRoman? It was to support legacy (last century?) images that did use macRoman encoded strings
Why latin1? Now images (squeak+pharo) uses unicode code-points that matches latin1 up to 256
Commit: 134b8f74a5d32226402ffd675e3845b5d4da7d9e
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/134b8f74a5d32226402ffd675e3845b5d4da7d9e Author: Nicolas Cellier <
[hidden email]>
Date: 2019-12-24 (Tue, 24 Dec 2019)
Changed paths:
M platforms/unix/vm-display-X11/sqUnixX11.c
Log Message:
-----------
Nuke recode entirely from unix X11
`recode` is used to translate the `charCode`... charCode is keyboard `event at: 3`.
From which encoding to which encoding? Err... charCode should be a keycode (keysym on X11).
So it should not be UTF8 or whatever. It's a keycode not a character code (code point).
Beside, charCode will use a single sqInt event slot, and a single byte is expected by image side.
Currently with my `fr_FR.UTF-8` locale, the VM is trying to translate a multi-byte encoded Character into 1-byte `charCode`.
This does not make sense.
Once upon a time, we used to encode the character into macRoman encoding, and used only the charCode at image side.
Now we should always use the ucs4 `event at: 6`, and we should STOP translating the charCode.
The charCode should be renamed keycode, and should just be that, a platform independent key code.
(including left shift, right shift, etc...).
key codes are useful for making lower level handlers at image side, handling key up and key down events.
Commit: 0dbcb71e9c53cb5c60023fa018d03e178117864f
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0dbcb71e9c53cb5c60023fa018d03e178117864f Author: Nicolas Cellier <
[hidden email]>
Date: 2019-12-24 (Tue, 24 Dec 2019)
Changed paths:
M platforms/unix/vm-display-X11/sqUnixX11.c
Log Message:
-----------
Directly use the symbolic (=virtual) key code, that's what we want.
With my fr_FR.UTF-8 locale, `buf` did contain a multi-byte sequence for non ASCII, thus putting `buf[0]` in `charCode`did not make much sense.
The defunct `recode`function did not improve anything, because it tried to convert `buf[0]`, kind of stupid obsolete code...
Note: we still use `translateCode` for having cross platform keycodes for arrows, page up/down and a few other non character keys.
We might want to generalize that to other keys! (I mean being cross platform).
Compare:
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/a54a2240565e%5E...0dbcb71e9c53
Locked
