[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Cross-platform differences for CTRL keys (#456)
notifications at github.com
Thu Dec 26 10:30:12 UTC 2019
I'm following the discussion on the background. I think you're right on using the keycode and not an ascii code. Using ascii to identify keys is a vestige from old "silly terminals". However, there are no keys in ascii to identify for example keys like ctrl, cmd or alt by themselves (and not as modifiers).
Regarding keyboard events (dunno about mousewheel in particular), my take here is that existing windowing/ui frameworks (cocoa/carbon, x11, windows forms..) send two different kind of events:
- key up / key down => identify wether a key is pressed or released with key code, no text is available. Here we can catch single ctrl/alt/cmd/F[X]/etc presses.
- a text event (which we call key press ourselves, maybe misleading) which sends text in some encoding as soon as it is available + associated modifiers
Now, the complication here to me is that historically morphic (in squeak and pharo, probably cuis still too?) has been using the text event to drive everything, even shortcuts. So the code managing keyup/downs is not used at all in my experience, and the code managing keypresses in morphs is overly complicated. And changing this while changing the VM at the same time can lead easily to a state where we cannot type :).
Now, as a single small step in what I believe is the right direction, I've implemented in Pharo mappings of keyboard virtual tables => the VM sends the raw virtual keycode to the image side (which depends on the platform) and on the image side this platform dependent virtual keycode is mapped to a common representation for all of them. Like that a single virtual key code table is used in client code. When I did that a couple of years ago, I've chosen to use "in image" X11's virtual key codes because it looked the broader and it seemed to contain the ones from osx and windows. Check https://github.com/pharo-project/pharo/blob/Pharo8.0/src/System-Platforms/KeyboardKey.class.st.
Then the idea is that morphic events are extended to get the correct key object with a double dispatch:
KeyboardEvent >> key
^Smalltalk os keyForValue: keyValue
UnixPlatform >> keyForValue: aKeyValue
^KeyboardKey valueForUnixPlatform: aKeyValue.
Still missing, some accessors for common keys like `KeyboardKey f11` `KeyboardKey ctrl`, which would allow for code like the following to open/close a morph while a key is being pressed (without an active wait ;)).
anEvent key = KeyboardKey alt
ifTrue: [ self openWindowSelector ]
anEvent key = KeyboardKey alt
ifTrue: [ self closeWindowSelector ]
A similar approach could be implemented vm side to map events. I like however the image one because it can be changed easily :)
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