Smalltalk › Squeak › Squeak - Dev

The Inbox: Kernel-mt.1287.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Jakob Reschke

Re: The Inbox: Kernel-mt.1287.mcz

tim Rowledge <[hidden email]> schrieb am Mi., 18. Dez. 2019, 20:28:

> On 2019-12-18, at 2:04 AM, Jakob Reschke <[hidden email]> wrote:
>
> The Ctrl key is not an anachronism. Its original function, zeroing the upper two bits of the pressed ASCII character, is.

I never knew that but it makes sense.

I only learned it from the Wikipedia article that Subbu linked to :-)

An issue we have to remember is that not all systems will actually send a keypress for 'only' a control (or alt, or command etc) key

True. And some systems don't even have a Ctrl key. Obviously you cannot target every platform if you make this key mapping choice.

But if it does come from the outside (key up, key down), Squeak should reveal it. Analogy: Not every system supports a Joystick, but if it does I want to be able to use it in Squeak. :-)

Jakob Reschke

Re: The Inbox: Kernel-mt.1287.mcz

In reply to this post by marcel.taeumel

Hi Marcel,

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

Marcel Taeumel <[hidden email]> 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

marcel.taeumel

Re: The Inbox: Kernel-mt.1287.mcz

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 <[hidden email]>:

Hi Marcel,

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

Marcel Taeumel <[hidden email]> 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

K K Subbu

Re: The Inbox: Kernel-mt.1287.mcz

In reply to this post by Jakob Reschke

On 19/12/19 4:39 AM, Jakob Reschke wrote:
> 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.

Partly right. Marcel's original post was to avoid confusion with
ctrl/alt modifiers and have a consistent way to handle them and
character keys in the image. I pointed out that modifiers are too low
level to handle in an image and so should be handled in a VM plugin.

My second point was that a keycode passed into an image is just a
number. It is the input handler in the Image which decodes it as a
Character or a command. Marcel's example assumed keycode as a Character
and an extra modifier to convert it to a command. But a numeric keycode
(like 16r03) may also hold a command (#copy). So a mapping is needed to
filter out commands from Characters in the Squeak Image input handler.
Objects outside of this input handler will only have to deal with
symbolic events not numeric events.

To summarize,

VM Input plugin - reads modifier and key pressed -> numeric keycode
Squeak Input handler - decodes numeric keycode into Character | Symbol
Squeak objects - perform symbols or accept Character

Regards .. Subbu