Hi Marcel,

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


Marcel Taeumel <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/4498e4a2/attachment.html>