[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Linux Squeak VM X11 keyboard changes breaks 32b VM (#396)
notifications at github.com
Tue Jun 11 16:58:26 UTC 2019
Hi Subbu, you made very good job at tracking the changes causing the problem, but I'm not sure that reverting is the right solution, this change was made for some reason. If we want to disentangle the code and remove some cruft we need better understanding. So let's focus on symptoms: CTRL+d is performing `debugIt:` rather than `doIt:` action.
So clearly, the CTRL/CMD or whatever modifier is taken into account, and transformation of keyValue to Ctrl-d code (0x4) is not necessary. It is not only not necessary, it also create various problems of interpretation of keyboard event, because 0x4 is also the encoding of END key, see implementors/senders of `specialShiftCmdKeys`. I played with various combinations of CTRL,ALT,OPTION,CMD,SHIFT + d on MacOS and Windows VM, and `HandMorph showEvents: true.`, and I can tell that it's messy all the way down!
The problem we observe in Squeak images is that the `TextEditor` performs the `shiftCmdActions` instead of the `cmdActions`. See `initializeCmdKeyShortcuts` and `initializeShiftCmdKeyShortcuts` in `SmalltalkEditor`. Why?
A good candidate for suspiscion is in `TextEditor>>dispatchOnKeyboardEvent:`
"the control key can be used to invoke shift-cmd shortcuts"
(honorCommandKeys and: [ aKeyboardEvent controlKeyPressed ])
ifTrue: [^ self
perform: (self class shiftCmdActions at: aKeyboardEvent keyValue + 1)
Ahah: I don't know if this is a MacOS-centric piece of code or what, but if we generate CTRL modifier instead of CMD modifier, maybe the image code ain't gonna perform the cmdActions, but rather the shiftCmdActions as we observe. Since you seem to identify a change in modifier state between old and new VM, this is maybe where we start inquiring instead.
The keyboard event is composed of several parts:
* keyValue code (`eventBuffer third` at image side) that tries to be an ASCII code + special codes for special keys (cursor, etc...) - as produced by `sq2KeyPlain` and friends.
* ucs4 (utf32) code for the character (`eventBuffer sixth`)
* keyboard modifiers (`eventBuffer fifth`) with a very complex dance in the VM.
But only one code is retained in the `KeyboardEvent` distributed for `Morph` consumption: either the keyValue, or the ucs4 code might be used, depending on Localized `World currentHand keyboardInterpreter class`. Most probably the ucs4 one nowadays if non null. By the way, what is your keyboardInterpreter class?
Note that Ctrl-d has some mapping in shiftCmdActions, "_thanks_" to this super hack in `initializeShiftCmdKeyShortcuts`
1 to: cmds size by: 2 do: [ :i |
cmdMap at: ((cmds at: i) asciiValue + 1) put: (cmds at: i + 1). "plain keys"
cmdMap at: ((cmds at: i) asciiValue - 32 + 1) put: (cmds at: i + 1). "shifted keys"
cmdMap at: ((cmds at: i) asciiValue - 96 + 1) put: (cmds at: i + 1). "ctrl keys"
which implies that shift-command `#debugIt:` associated to $d (100 0x64) will also be associated to $D (68 0x44) and to Ctrl-d (4 0x04).
But I do not see any thing like that in cmdActions, `SmalltalkEditor cmdActions occurrencesOf: #doIt:` answers 1, it is associated to $d only.
You see that this would/could conflict with END key special actions (same for other special keys encoding), which is a bad thing. The Ctlr-d (0x4) value & co are a bad thing coming from the past (like console mode compatibility) that we do not need, neither at low level keyboard handling (KeyUp KeyDown), nor at higher level synthetic event handling (KeyStroke/KeyChar). I think we'd better keep the change you legitimately incriminated, and I would rather try to understand all the implications of `translateCode` and when/how it handles the modifier states instead...
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev