Hi Jakob.

> If things went my way, you would handle the Ctrl+C gesture as a key down (or up) event. Key char/stroke is for text input (mostly).

Agreed! We should really work on making key down/up consistent across all platforms. No platform-specific (virtual) key codes should bleed into the image. Let us be inspired from the folks at SDL (https://www.libsdl.org/).

Best,
Marcel
Am 19.12.2019 00:09:49 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Hi Marcel, 

Let me reply to you as the topic opener for a change ;-)


Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> schrieb am Mo., 16. Dez. 2019, 11:24:

I argue for a consistent representation of modifiers (ctrl, cmd/alt, shift, (opt), ...) and key characters. The following example is not possible at the moment but should:


MyMorph >> #handlesKeyboard: evt
   ^ true
MyMorph >> #keyStroke: evt
  (evt controlKeyPressed and: [evt keyCharacter = $c])
      ifTrue: [self terminateApplication].

Why? Because there might be the requirement to "terminate on ctrl+c" for some application and it would be nice if one could just implement it that way. :-)

But maybe I am confusing "characters" and "keys" again. Happens way too quickly.

If things went my way, you would handle the Ctrl+C gesture as a key down (or up) event. Key char/stroke is for text input (mostly). For example, it will repeat (at the environment's discretion) if you hold the keys down. To be able to handle Ctrl+C as key down/up, there should be a platform-independent way to represent "the key C". Today we get the environment/platform-specific key code (correct?), and instead it should be a Squeak-defined unified code (for a keyboard button in this case).

If I understand Subbu correctly after re-reading the thread, he would like that you handle/implement a #terminate message instead. Ctrl+C is mapped to #terminate by an input plugin in this scenario. And Subbu seems to count this #terminate among the "virtual key codes". The mapping in the plugin would be configurable, like with xmodmap for X Server. @Subbu please correct me if I still got you wrong.

I argue that such high-level key mapping should be done in the image and on top of unified virtual key codes. Plugins are harder to change. Moreover key mapping should work application-specific and multiple applications can run in the same Squeak image. In particular if it is a "developer image". I imagine this would be more difficult if the mapping happens in a plugin. However, I agree that such general mapping, if implemented, should happen outside of (or rather before) Morphic.

Finally in my opinion we should not lose the possibility of letting an application handle a keyboard as it is, with at last Ctrl, Alt, Shift and their Mac equivalents, and possibly other modifiers. Hence no enforced/required mapping of "low level key combinations" to "high level messages", only a mapping of "platform specific key codes" to "unified key codes for Squeak".

Maybe we could have both approaches at the same time. And maybe it does make sense to rename the modifiers to get around the Cmd vs Ctrl (or Alt?) problem. The mouse buttons are already called red, yellow, blue... And which one is which is then really something for the plugins.

Kind regards
Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191219/0ed25a37/attachment-0001.html>