[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Cross-platform differences for CTRL keys (#456)

[Guille Polito]

Hi Nicolas,

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:

```smalltalk
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 ;)).

```smalltalk
MyMorph>>keyDown: anEvent
	anEvent key = KeyboardKey alt
             ifTrue: [ self openWindowSelector ]

MyMorph>>keyUp: anEvent
	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:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456#issuecomment-569033678
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191226/0f509d40/attachment-0001.html>