The Inbox: Kernel-mt.1287.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The Inbox: Kernel-mt.1287.mcz

commits-2
A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-mt.1287.mcz

==================== Summary ====================

Name: Kernel-mt.1287
Author: mt
Time: 13 December 2019, 4:30:11.846615 pm
UUID: 1e52cdbe-487d-ed47-8510-c491c1d57fca
Ancestors: Kernel-mt.1286

Proposal: Always map control characters to printable characters. This happens automatically when "duplicate (all) control and alt keys" or "swap control and alt keys" is enabled. But NOT when all of those preferences are disabled. Which can be surprising because when you type [ctrl]+[c], you expect a key value of 99 like in [cmd/alt]+[c]. ... and not 3 :-)

This is a proposal because we also would have to adapt and test:

TextEditor >> #dispatchOnKeyboardEvent:
TextEditor class >> #initializeShiftCmdKeyShortcuts
Editor class >> #specialShiftCmdKeys

=============== Diff against Kernel-mt.1286 ===============

Item was added:
+ ----- Method: EventSensor class>>installControlKeyEntryFor: (in category 'key decode table') -----
+ installControlKeyEntryFor: c
+ "Updates key-decode table. The table maps pairs of {character code . modifier code}. See the class comment for more information. Note that the bitmask 16r9F is used to convert control characters (ascii 0 to 31) to printable characters."
+
+ | upper lower |
+ upper := c asUppercase asInteger.
+ lower := c asLowercase asInteger.
+
+ KeyDecodeTable at: { lower bitAnd: 16r9F . 2 "ctrl" } put: { lower . 2 "ctrl"  }.
+ KeyDecodeTable at: { upper bitAnd: 16r9F . 2 bitOr: 1 "ctrl+shift" } put: { upper . 2 bitOr: 1 "ctrl+shift" }.
+ !

Item was changed:
  ----- Method: EventSensor class>>installKeyDecodeTable (in category 'class initialization') -----
  installKeyDecodeTable
  "Create a decode table that swaps some keys if
  Preferences swapControlAndAltKeys is set"
  KeyDecodeTable := Dictionary new.
+
+ "In any case, translate all control characters to printable characters."
+ 64 +1 "because 0 is special, see UTF32InputInterpreter"
+ to: 95 -2 "except for our mouse-wheel up/down hack"
+ do: [:keyCode | self installControlKeyEntryFor: keyCode asCharacter].
+
  Preferences duplicateControlAndAltKeys
  ifTrue: [ self defaultCrossPlatformKeys do:
  [ :c | self installDuplicateKeyEntryFor: c ] ].
  Preferences swapControlAndAltKeys
  ifTrue: [ self defaultCrossPlatformKeys do:
  [ :c | self installSwappedKeyEntryFor: c ] ].
  Preferences duplicateAllControlAndAltKeys
  ifTrue: [ (Character allByteCharacters select: [:ea | ea isAlphaNumeric]) do:
  [ :c | self installDuplicateKeyEntryFor: c ] ].
  !


Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
> This happens automatically when "duplicate (all) control and alt keys" or "swap control and alt keys" is enabled.

Let me correct this. The preference "swap control and alt keys" does *not* map control keys to printable characters. Just swapping. I think we should rename "Duplicate (all) control and alt keys" to "Overwrite all control keys with alt/command keys".

Sigh.

Best,
Marcel

Am 13.12.2019 16:30:26 schrieb [hidden email] <[hidden email]>:

A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-mt.1287.mcz

==================== Summary ====================

Name: Kernel-mt.1287
Author: mt
Time: 13 December 2019, 4:30:11.846615 pm
UUID: 1e52cdbe-487d-ed47-8510-c491c1d57fca
Ancestors: Kernel-mt.1286

Proposal: Always map control characters to printable characters. This happens automatically when "duplicate (all) control and alt keys" or "swap control and alt keys" is enabled. But NOT when all of those preferences are disabled. Which can be surprising because when you type [ctrl]+[c], you expect a key value of 99 like in [cmd/alt]+[c]. ... and not 3 :-)

This is a proposal because we also would have to adapt and test:

TextEditor >> #dispatchOnKeyboardEvent:
TextEditor class >> #initializeShiftCmdKeyShortcuts
Editor class >> #specialShiftCmdKeys

=============== Diff against Kernel-mt.1286 ===============

Item was added:
+ ----- Method: EventSensor class>>installControlKeyEntryFor: (in category 'key decode table') -----
+ installControlKeyEntryFor: c
+ "Updates key-decode table. The table maps pairs of {character code . modifier code}. See the class comment for more information. Note that the bitmask 16r9F is used to convert control characters (ascii 0 to 31) to printable characters."
+
+ | upper lower |
+ upper := c asUppercase asInteger.
+ lower := c asLowercase asInteger.
+
+ KeyDecodeTable at: { lower bitAnd: 16r9F . 2 "ctrl" } put: { lower . 2 "ctrl" }.
+ KeyDecodeTable at: { upper bitAnd: 16r9F . 2 bitOr: 1 "ctrl+shift" } put: { upper . 2 bitOr: 1 "ctrl+shift" }.
+ !

Item was changed:
----- Method: EventSensor class>>installKeyDecodeTable (in category 'class initialization') -----
installKeyDecodeTable
"Create a decode table that swaps some keys if
Preferences swapControlAndAltKeys is set"
KeyDecodeTable := Dictionary new.
+
+ "In any case, translate all control characters to printable characters."
+ 64 +1 "because 0 is special, see UTF32InputInterpreter"
+ to: 95 -2 "except for our mouse-wheel up/down hack"
+ do: [:keyCode | self installControlKeyEntryFor: keyCode asCharacter].
+
Preferences duplicateControlAndAltKeys
ifTrue: [ self defaultCrossPlatformKeys do:
[ :c | self installDuplicateKeyEntryFor: c ] ].
Preferences swapControlAndAltKeys
ifTrue: [ self defaultCrossPlatformKeys do:
[ :c | self installSwappedKeyEntryFor: c ] ].
Preferences duplicateAllControlAndAltKeys
ifTrue: [ (Character allByteCharacters select: [:ea | ea isAlphaNumeric]) do:
[ :c | self installDuplicateKeyEntryFor: c ] ].
!




Reply | Threaded
Open this post in threaded view
|

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

K K Subbu
On 13/12/19 9:05 PM, Marcel Taeumel wrote:
> Let me correct this. The preference "swap control and alt keys" does
> *not* map control keys to printable characters. Just swapping. I think
> we should rename "Duplicate (all) control and alt keys" to "Overwrite
> all control keys with alt/command keys".

Is this preference really necessary? It just compounds the confusion.
CTRL (keyboard device) and ALT (application modifier) operate at
different levels of abstraction.

It is about time we contained traditional modifiers like CAPSLOCK/SHIFT
and CTRL within input plugins. Let plugins use these modifiers to map
key code 16r40..5f<->16r60..7f and 16r40..16r5f->16r00..16r2f.

Only ALT (CMD on Mac) modifier needs to be passed to the image and
handled its input handlers. Mouse buttons should be checked only with
ALT/CMD and not low level modifiers.

This separation of modifiers should simplify both the VM and the Image
code and be consistent with their intended meaning.

All we need is a new preference that states that VM will handle
machine-specific modifiers ;-).

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke

K K Subbu <[hidden email]> schrieb am So., 15. Dez. 2019, 12:15:

It is about time we contained traditional modifiers like CAPSLOCK/SHIFT
and CTRL within input plugins. Let plugins use these modifiers to map
key code 16r40..5f<->16r60..7f and 16r40..16r5f->16r00..16r2f.

Only ALT (CMD on Mac) modifier needs to be passed to the image and
handled its input handlers. Mouse buttons should be checked only with
ALT/CMD and not low level modifiers.

Did I get that wrong or are you really suggesting to make Ctrl unavailable as a modifier inside of Squeak?

Many "normal" applications map Ctrl combinations. Most do so before they begin to map Alt. At least on Windows and Linux. Ctrl to them is what Cmd is to Mac, that's how I observed it.

I wish that both modifiers are available for the Squeak IDE and applications. That they are blurred as they are now and can't be reliably used together is a long-standing bug in my opinion. It severely limits the space of reliably-available shortcut key combinations.


Reply | Threaded
Open this post in threaded view
|

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

Stéphane Rollandin
>     It is about time we contained traditional modifiers like CAPSLOCK/SHIFT
>     and CTRL within input plugins. Let plugins use these modifiers to map
>     key code 16r40..5f<->16r60..7f and 16r40..16r5f->16r00..16r2f.
>
>     Only ALT (CMD on Mac) modifier needs to be passed to the image and
>     handled its input handlers. Mouse buttons should be checked only with
>     ALT/CMD and not low level modifiers.
>
>
> Did I get that wrong or are you really suggesting to make Ctrl
> unavailable as a modifier inside of Squeak?

-1 for me if this is the case.

I do use Ctrl + mouse gestures in some morphs, for example.

Stef

Reply | Threaded
Open this post in threaded view
|

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

K K Subbu
In reply to this post by Jakob Reschke
On 15/12/19 6:02 PM, Jakob Reschke wrote:
> Did I get that wrong or are you really suggesting to make Ctrl
> unavailable as a modifier inside of Squeak?
>
> Many "normal" applications map Ctrl combinations. Most do so before they
> begin to map Alt. At least on Windows and Linux. Ctrl to them is what
> Cmd is to Mac, that's how I observed it.

Yes. My strawman proposal is to simplify code (VM and Image) through
separation of concerns and eliminate confusion across platforms. I don't
expect it to affect Squeak keyboard habits much [1]

VM input plugins will use modifiers like CTRL, SHIFT, CAPLOCK to decode
key presses and pass a "soft" keycode to the Image. For instance, when
you press Ctrl+C, the VM will decode this into 16r03 and pass it to the
Image. The Image will treat this as a "copy" command.Within the image,
non-printable codes will map directly to commands like cut (ctrl-x),
copy (ctrl-c), paste (ctrl-v), print (ctrl-p), open (ctrl-o), save
(ctrl-s), close (ctrl-w), quit (ctrl-q). ALT modifier is used to
interpret printable keys as commands like doit (alt-d), browse (alt-b) etc.

[1] Platforms often use modifier combinations to bypass apps, enter
accented characters or Unicode. Eg. CTRL+ALT on Linux, CMD+Option on
Mac) bypass applications and send commands directly to boot, host os or
the window manager. Other combinations like CTRL+SHIFT (Linux) or Option
(Mac) or ALT+Numeric+ (Windows) are used to enter any 4-nibble Unicode.
The Image should not have to deal with such low level detail. Let VM
input plugins handle these escapes gracefully.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
Hi all! :-)

I do not propose a loss of information, just a more consistent view on it with fewer special cases in the lower abstraction levels.

The goal is to provide a clean object representation for input events. So, we should simplify the data exchange between VM and image but keep it cross-platform compatible.

If anybody wants to implement a terminal-like application within Squeak, it is very simple to convert "anEvent controlKeyPressed and: [anEvent keyValue >= 64]" to that non-printable ascii range. However, I argue that this detail should not bleed into applications by default. And as long as VMs send those control characters for [ctrl]-combinations, EventSensor could unpack those to make typing [ctrl]+[0] behave like typing [ctrl]+[c].

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.

Maybe "ctrl" is no modifier at all? Sigh.

Best,
Marcel

P.S.: I want function keys, too! :-D

Am 16.12.2019 07:13:04 schrieb K K Subbu <[hidden email]>:

On 15/12/19 6:02 PM, Jakob Reschke wrote:
> Did I get that wrong or are you really suggesting to make Ctrl
> unavailable as a modifier inside of Squeak?
>
> Many "normal" applications map Ctrl combinations. Most do so before they
> begin to map Alt. At least on Windows and Linux. Ctrl to them is what
> Cmd is to Mac, that's how I observed it.

Yes. My strawman proposal is to simplify code (VM and Image) through
separation of concerns and eliminate confusion across platforms. I don't
expect it to affect Squeak keyboard habits much [1]

VM input plugins will use modifiers like CTRL, SHIFT, CAPLOCK to decode
key presses and pass a "soft" keycode to the Image. For instance, when
you press Ctrl+C, the VM will decode this into 16r03 and pass it to the
Image. The Image will treat this as a "copy" command.Within the image,
non-printable codes will map directly to commands like cut (ctrl-x),
copy (ctrl-c), paste (ctrl-v), print (ctrl-p), open (ctrl-o), save
(ctrl-s), close (ctrl-w), quit (ctrl-q). ALT modifier is used to
interpret printable keys as commands like doit (alt-d), browse (alt-b) etc.

[1] Platforms often use modifier combinations to bypass apps, enter
accented characters or Unicode. Eg. CTRL+ALT on Linux, CMD+Option on
Mac) bypass applications and send commands directly to boot, host os or
the window manager. Other combinations like CTRL+SHIFT (Linux) or Option
(Mac) or ALT+Numeric+ (Windows) are used to enter any 4-nibble Unicode.
The Image should not have to deal with such low level detail. Let VM
input plugins handle these escapes gracefully.

Regards .. Subbu



Reply | Threaded
Open this post in threaded view
|

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

K K Subbu
On 16/12/19 3:54 PM, Marcel Taeumel wrote:
> 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. :-)

Morphic is a GUI. Its input handler should not have to deal with
host-specific modifiers and just map keycodes to selectors (commands).

VM input plugin will parse CTRL+Q into keycode 16r11 to Squeak. Morphic
input handler will map this keycode to, say, #quitKey. so you should
just be able to write:

MyMorph>>quitKey
        self terminateApplication

Later if we want to allow ALT+Q also to quit, then we just need to add a
single entry to the Morphic keycode map.

> But maybe I am confusing "characters" and "keys" again. Happens way too
> quickly.
It happens to me too, especially when working late into the night ;-).

I think of a keycode as a SmallInt (or sequence of SmallInts) that
encodes a Character or Symbol (selector), just like a machine word
encoding integer or oop.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
Morphic is a GUI. Its input handler should not have to deal with host-specific modifiers and just map keycodes to selectors (commands).

The representation of such user-input events is not necessarily specific to Morphic, only that #keyStroke: interface is. In the long term, it would be nice to move "UserInputEvent" etc. out of Morphic into its own base package. This is a matter of finding a consistent, object-oriented representation for user-input events. :-) 

I think the acual question is whether CTRL is a modifier key or not. As it appears here, CTRL does not only modify a key (character) but actually *modifies* a key (character). :-D Then, again, SHIFT does this, too. Hmmm...

Best,
Marcel

Am 16.12.2019 15:47:57 schrieb K K Subbu <[hidden email]>:

On 16/12/19 3:54 PM, Marcel Taeumel wrote:
> 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. :-)

Morphic is a GUI. Its input handler should not have to deal with
host-specific modifiers and just map keycodes to selectors (commands).

VM input plugin will parse CTRL+Q into keycode 16r11 to Squeak. Morphic
input handler will map this keycode to, say, #quitKey. so you should
just be able to write:

MyMorph>>quitKey
self terminateApplication

Later if we want to allow ALT+Q also to quit, then we just need to add a
single entry to the Morphic keycode map.

> But maybe I am confusing "characters" and "keys" again. Happens way too
> quickly.
It happens to me too, especially when working late into the night ;-).

I think of a keycode as a SmallInt (or sequence of SmallInts) that
encodes a Character or Symbol (selector), just like a machine word
encoding integer or oop.

Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

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

K K Subbu
On 16/12/19 8:24 PM, Marcel Taeumel wrote:
> The representation of such user-input events is not necessarily specific
> to Morphic, only that #keyStroke: interface is. In the long term, it
> would be nice to move "UserInputEvent" etc. out of Morphic into its own
> base package. This is a matter of finding a consistent, object-oriented
> representation for user-input events. :-)

Right. key is a physical button while keycode is what is generated by
keyboard driver. keycode is a low-level numeric code. Morphic should
only deal with objects like character or selector.

> it appears here, CTRL does not only modify a key (character) but
> actually *modifies* a key (character). :-D Then, again, SHIFT does this,
> too. Hmmm...

I had to read that a couple of times to understand it ;-). CTRL modifies
a keycode not a character. It was introduced to accommodate the
limitations of a physical keyboard. This is why soft keyboards (like the
ones on smartphones) don't need one.

  https://en.wikipedia.org/wiki/Control_key
  https://en.wikipedia.org/wiki/Alt_key

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier


Le lun. 16 déc. 2019 à 16:50, K K Subbu <[hidden email]> a écrit :
On 16/12/19 8:24 PM, Marcel Taeumel wrote:
> The representation of such user-input events is not necessarily specific
> to Morphic, only that #keyStroke: interface is. In the long term, it
> would be nice to move "UserInputEvent" etc. out of Morphic into its own
> base package. This is a matter of finding a consistent, object-oriented
> representation for user-input events. :-)

Right. key is a physical button while keycode is what is generated by
keyboard driver. keycode is a low-level numeric code. Morphic should
only deal with objects like character or selector.

Note that there is one more level of distinction:
- for windows, the scancode is the low-level keyboard-specific encoding (decoded by keyboard driver)
- in windows events the scancode is converted to a virtual keycode, which is device independent (VK_Enter for Enter key, etc...)
- similarly to virtual keycode, there are keysym on unix (X11)


The same key on keyboard can generate several characters (a A ä ...), whether Shift, Alt Gr; or a composition key where pressed, or depending on status of caps lock, num lock, etc...
The fact that there is a different scancode generated or not when shift/ctrl is pressed is a low level implementation detail.

We might want to have an OS independant virtual code as charCode for key up and key down events...
That's already the case for arrows, home, end, page up, page down and a few other controls...


> it appears here, CTRL does not only modify a key (character) but
> actually *modifies* a key (character). :-D Then, again, SHIFT does this,
> too. Hmmm...

I had to read that a couple of times to understand it ;-). CTRL modifies
a keycode not a character. It was introduced to accommodate the
limitations of a physical keyboard. This is why soft keyboards (like the
ones on smartphones) don't need one.

  https://en.wikipedia.org/wiki/Control_key
  https://en.wikipedia.org/wiki/Alt_key

Regards .. Subbu

This was the case on legacy keyboard for legacy apps (typewritter and console apps)
Nowadays CTRL modifies the WM_CHAR event, but the keycode remains unchanged for WM_KEYDOWN and WM_KEYUP events...
So it's not the virtual keycode which is modified! (maybe the scancode, we don't care, too low level)

The idiomatic handling CTRL may vary on different OS: windows recommend handling control+key shortcuts at keydown event, and more idiomatically thru AcceleratorTable...
Probably not universal enough for being in the VM...

Do we really want to generate Start of Heading control code with the keyboard for Squeak consumption? i doubt... If we would want that, we would emulate it.
But we probably want to be able to distinguish CTRL+M from Control+Enter/Return...


Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
In reply to this post by K K Subbu
@Subbu: I am not completely convinced. I agree with your observations but I think your conclusions to the design of the interface are different than mine.

Tl;dr: proposal section at the bottom.

Selectors are names and as such carry a meaning (hopefully). So if you code Ctrl+Q to mean #quit, then you make it fix for all possible applications. Ctrl+Q does not generally quit Windows applications, Alt+F4 does.

Is F1 #showHelp or #goToFirstPage?
Is F10 #openApplicationMenu, #decreaseFrameRate or #showHighScore?
Is Esc #escape or #showYellowKeyMenu?
Is Ctrl+A #selectAll or #moveToBeginning?

If the environment (OS or window manager or input/output system) assigns its own meaning to a combination it will do so before it reaches Squeak anyway. So if Ctrl+Alt+C were the copyright symbol for some environment, the key char/stroke event arriving in Squeak should contain the copyright character alright, without further doing of either plugins or the image. Quit messages should not be determined from keys at all (that is by Squeak or Morphic, an application in Squeak may do so). The environment will send a proper quit/close request to the application/window in a different message that is not the same as the key event message.

So if this environment specific quit message is mapped to a quit event by the VM and then eventually to a #quit send by the image, then I would agree. But not to magically converting Ctrl+Q key events to anything else than "q was pressed with the Ctrl modifier", at least for key down and key up. The character might differ for key char (as in the copyright symbol example above).

And for key up and key down, other systems have virtual key codes. Squeak should have them too (to finally abstract away the platform differences of the current key codes). But the VK for Ctrl+Q should be VK_Q (with modifier Ctrl), not VK_QUIT.

The Wikipedia page even says that this mapping of Ctrl+C and others to the control characters is an anachronism from the teletypewriter era. By all practical means today Ctrl is a modifier like Alt and the meaning is assigned by software, that is application or environment. To maintain flexibility, we should not deprive applications written in Squeak/Morphic from the opportunity to handle Ctrl themselves. If you make a choice for one convention, you will alienate Squeak applications on another platform and Squeak should not in general pretend to "be the platform" IMHO (except when it really is and runs as OS/window manager).

Note that I don't see a problem in mapping Ctrl-W to self changed: #close for SystemWindows. Then ToolBuilder is "the environment" (or "the application" from the outside). But as outlined above, Morphic should IMHO not assume the role of either because it is too general.

Proposal:
- Key up and key down events with virtual key codes that map actual keyboard keys, not functions, with all possible  modifiers, including Ctrl and Shift.
- No assignment of meaning to those by either VM, EventSensor, ... or Morphic.
- Key Char (key stroke) event with environment-determined character in them. No modifiers at all! Uppercase characters should come in as such already, no need to look at Shift. If composed characters come in when they are finished they are taken as they are.
- The environment may send an ongoing composition as other events. It should be up to a preference whether something in Squeak handles these, to do the composition in Squeak itself.
- Additional functional event types such as quit, copy, minimize, show context menu etc if the platform-specific input plugin supports them. There are a bunch of Windows messages out there and X surely has its own. Control via preferences whether they go to the image or to the VM window itself, where it makes sense. 
- More input event types other than keyboard keys, such as scroll up with wheel, swipe right with 3 fingers, start dragging something out, dragged something in, dropped something etc. if the platform-specific input plugin supports them.

Sorry for the long text and probably repeating myself several times.

Kind regards
Jakob


K K Subbu <[hidden email]> schrieb am Mo., 16. Dez. 2019, 16:50:
On 16/12/19 8:24 PM, Marcel Taeumel wrote:
> The representation of such user-input events is not necessarily specific
> to Morphic, only that #keyStroke: interface is. In the long term, it
> would be nice to move "UserInputEvent" etc. out of Morphic into its own
> base package. This is a matter of finding a consistent, object-oriented
> representation for user-input events. :-)

Right. key is a physical button while keycode is what is generated by
keyboard driver. keycode is a low-level numeric code. Morphic should
only deal with objects like character or selector.

> it appears here, CTRL does not only modify a key (character) but
> actually *modifies* a key (character). :-D Then, again, SHIFT does this,
> too. Hmmm...

I had to read that a couple of times to understand it ;-). CTRL modifies
a keycode not a character. It was introduced to accommodate the
limitations of a physical keyboard. This is why soft keyboards (like the
ones on smartphones) don't need one.

  https://en.wikipedia.org/wiki/Control_key
  https://en.wikipedia.org/wiki/Alt_key

Regards .. Subbu




Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
In reply to this post by Nicolas Cellier
...looks like Nicolas was faster. While I was still typing my monster message on the phone... without a Ctrl key ;-)

But I assume the smartphone keyboards only generate what is the keystroke event in Morphic, not key up or key down.


Nicolas Cellier <[hidden email]> schrieb am Mo., 16. Dez. 2019, 19:46:


Le lun. 16 déc. 2019 à 16:50, K K Subbu <[hidden email]> a écrit :
On 16/12/19 8:24 PM, Marcel Taeumel wrote:
> The representation of such user-input events is not necessarily specific
> to Morphic, only that #keyStroke: interface is. In the long term, it
> would be nice to move "UserInputEvent" etc. out of Morphic into its own
> base package. This is a matter of finding a consistent, object-oriented
> representation for user-input events. :-)

Right. key is a physical button while keycode is what is generated by
keyboard driver. keycode is a low-level numeric code. Morphic should
only deal with objects like character or selector.

Note that there is one more level of distinction:
- for windows, the scancode is the low-level keyboard-specific encoding (decoded by keyboard driver)
- in windows events the scancode is converted to a virtual keycode, which is device independent (VK_Enter for Enter key, etc...)
- similarly to virtual keycode, there are keysym on unix (X11)


The same key on keyboard can generate several characters (a A ä ...), whether Shift, Alt Gr; or a composition key where pressed, or depending on status of caps lock, num lock, etc...
The fact that there is a different scancode generated or not when shift/ctrl is pressed is a low level implementation detail.

We might want to have an OS independant virtual code as charCode for key up and key down events...
That's already the case for arrows, home, end, page up, page down and a few other controls...


> it appears here, CTRL does not only modify a key (character) but
> actually *modifies* a key (character). :-D Then, again, SHIFT does this,
> too. Hmmm...

I had to read that a couple of times to understand it ;-). CTRL modifies
a keycode not a character. It was introduced to accommodate the
limitations of a physical keyboard. This is why soft keyboards (like the
ones on smartphones) don't need one.

  https://en.wikipedia.org/wiki/Control_key
  https://en.wikipedia.org/wiki/Alt_key

Regards .. Subbu

This was the case on legacy keyboard for legacy apps (typewritter and console apps)
Nowadays CTRL modifies the WM_CHAR event, but the keycode remains unchanged for WM_KEYDOWN and WM_KEYUP events...
So it's not the virtual keycode which is modified! (maybe the scancode, we don't care, too low level)

The idiomatic handling CTRL may vary on different OS: windows recommend handling control+key shortcuts at keydown event, and more idiomatically thru AcceleratorTable...
Probably not universal enough for being in the VM...

Do we really want to generate Start of Heading control code with the keyboard for Squeak consumption? i doubt... If we would want that, we would emulate it.
But we probably want to be able to distinguish CTRL+M from Control+Enter/Return...



Reply | Threaded
Open this post in threaded view
|

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

K K Subbu
In reply to this post by Jakob Reschke
On 17/12/19 12:52 AM, Jakob Reschke wrote:
> Selectors are names and as such carry a meaning (hopefully). So if you
> code Ctrl+Q to mean #quit, then you make it fix for all possible
> applications. Ctrl+Q does not generally quit Windows applications,
> Alt+F4 does.

Please don't take the symbol literally. I just threw in #quit as a soft
keycode. Squeak is a virtual machine. It can define its own soft keys.
The question is - should these keys mimic hardware of the past or can we
reify them at a higher level today? If so, where should the physical
keys be converted into virtual keycodes - in the input plugin, in the VM
event handler or in the keyboard handler in the Image?

> So if this environment specific quit message is mapped to a quit event
> by the VM and then eventually to a #quit send by the image, then I would
> agree. But not to magically converting Ctrl+Q key events to anything
> else than "q was pressed with the Ctrl modifier", at least for key down
> and key up. The character might differ for key char (as in the copyright
> symbol example above).

Squeak Image, being a multi-platform, cannot make assumptions about
specific modifiers on a physical keyboard or specific input composition
methods on host OS. The input plugin, which is tied to a host, should
encapsulate such details.

> And for key up and key down, other systems have virtual key codes.
> Squeak should have them too (to finally abstract away the platform
> differences of the current key codes). But the VK for Ctrl+Q should be
> VK_Q (with modifier Ctrl), not VK_QUIT.

But CTRL+VK_Q simply passes on Ctrl handling into the Image and that
breaks encapsulation. The VM just offers two virtual input streams -
keyboard and motion inputs - and defines a list of virtual event codes
that the VM will report to the Image. The exact way in which these are
computed from the physical devices (keyboard, joystick, touchpad, mouse
etc) should be abstracted by input plugins (with a dynamically
configurable mapping - see XServer below).

> The Wikipedia page even says that this mapping of Ctrl+C and others to
> the control characters is an anachronism from the teletypewriter era. By
> all practical means today Ctrl is a modifier like Alt and the meaning is
> assigned by software, that is application or environment. To maintain
> flexibility, we should not deprive applications written in
> Squeak/Morphic from the opportunity to handle Ctrl themselves.

The statements are contradictory. If ctrl is anachronistic then why pass
it along to Squeak Image instead of factoring it out in the input plugin?

> Proposal:
> - Key up and key down events with virtual key codes that map actual
> keyboard keys, not functions, with all possible  modifiers, including
> Ctrl and Shift. > - No assignment of meaning to those by either VM, EventSensor, ... or
> Morphic.

This means that we are not abstracting input devices at all. Soft
keyboards on Android or iPad may not have ctrl or alt keys.

My proposal is to interpret modifiers within input plugins like the way
other multi-platform software handle them. For instance, Linux (another
multi-platform OS) defines these virtual codes that are mapped at the
input driver level :

 
https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h

XServer which runs on multiple OSes defines its own set of abstract
keycodes (keysyms) mapped by its input drivers and uses a tool to change
the mapping at any time:

  https://www.x.org/archive/X11R6.8.1/doc/xmodmap.1.html


> - Key Char (key stroke) event with environment-determined character in
> them. No modifiers at all! Uppercase characters should come in as such
> already, no need to look at Shift. If composed characters come in when
> they are finished they are taken as they are.

agreed. Makes sense.

> - The environment may send an ongoing composition as other events. It
> should be up to a preference whether something in Squeak handles these,
> to do the composition in Squeak itself.

We may need this preference until we can move the logic into input plugins.

> - Additional functional event types such as quit, copy, minimize, show
> context menu etc if the platform-specific input plugin supports them.
> There are a bunch of Windows messages out there and X surely has its
> own. Control via preferences whether they go to the image or to the VM
> window itself, where it makes sense.
> - More input event types other than keyboard keys, such as scroll up
> with wheel, swipe right with 3 fingers, start dragging something out,
> dragged something in, dropped something etc. if the platform-specific
> input plugin supports them.

Yes. We need to capture all these inputs into virtual keycodes.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
Hi Nicolas, hi all!

I documented the status quo here:

Note that this discussion has nothing to do with those mappings in TextEditor because those can easily be cleaned up once the communication between VM and image got cleaned up.

Best,
Marcel

Am 17.12.2019 08:03:59 schrieb K K Subbu <[hidden email]>:

On 17/12/19 12:52 AM, Jakob Reschke wrote:
> Selectors are names and as such carry a meaning (hopefully). So if you
> code Ctrl+Q to mean #quit, then you make it fix for all possible
> applications. Ctrl+Q does not generally quit Windows applications,
> Alt+F4 does.

Please don't take the symbol literally. I just threw in #quit as a soft
keycode. Squeak is a virtual machine. It can define its own soft keys.
The question is - should these keys mimic hardware of the past or can we
reify them at a higher level today? If so, where should the physical
keys be converted into virtual keycodes - in the input plugin, in the VM
event handler or in the keyboard handler in the Image?

> So if this environment specific quit message is mapped to a quit event
> by the VM and then eventually to a #quit send by the image, then I would
> agree. But not to magically converting Ctrl+Q key events to anything
> else than "q was pressed with the Ctrl modifier", at least for key down
> and key up. The character might differ for key char (as in the copyright
> symbol example above).

Squeak Image, being a multi-platform, cannot make assumptions about
specific modifiers on a physical keyboard or specific input composition
methods on host OS. The input plugin, which is tied to a host, should
encapsulate such details.

> And for key up and key down, other systems have virtual key codes.
> Squeak should have them too (to finally abstract away the platform
> differences of the current key codes). But the VK for Ctrl+Q should be
> VK_Q (with modifier Ctrl), not VK_QUIT.

But CTRL+VK_Q simply passes on Ctrl handling into the Image and that
breaks encapsulation. The VM just offers two virtual input streams -
keyboard and motion inputs - and defines a list of virtual event codes
that the VM will report to the Image. The exact way in which these are
computed from the physical devices (keyboard, joystick, touchpad, mouse
etc) should be abstracted by input plugins (with a dynamically
configurable mapping - see XServer below).

> The Wikipedia page even says that this mapping of Ctrl+C and others to
> the control characters is an anachronism from the teletypewriter era. By
> all practical means today Ctrl is a modifier like Alt and the meaning is
> assigned by software, that is application or environment. To maintain
> flexibility, we should not deprive applications written in
> Squeak/Morphic from the opportunity to handle Ctrl themselves.

The statements are contradictory. If ctrl is anachronistic then why pass
it along to Squeak Image instead of factoring it out in the input plugin?

> Proposal:
> - Key up and key down events with virtual key codes that map actual
> keyboard keys, not functions, with all possible  modifiers, including
> Ctrl and Shift. > - No assignment of meaning to those by either VM, EventSensor, ... or
> Morphic.

This means that we are not abstracting input devices at all. Soft
keyboards on Android or iPad may not have ctrl or alt keys.

My proposal is to interpret modifiers within input plugins like the way
other multi-platform software handle them. For instance, Linux (another
multi-platform OS) defines these virtual codes that are mapped at the
input driver level :


https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h

XServer which runs on multiple OSes defines its own set of abstract
keycodes (keysyms) mapped by its input drivers and uses a tool to change
the mapping at any time:

https://www.x.org/archive/X11R6.8.1/doc/xmodmap.1.html


> - Key Char (key stroke) event with environment-determined character in
> them. No modifiers at all! Uppercase characters should come in as such
> already, no need to look at Shift. If composed characters come in when
> they are finished they are taken as they are.

agreed. Makes sense.

> - The environment may send an ongoing composition as other events. It
> should be up to a preference whether something in Squeak handles these,
> to do the composition in Squeak itself.

We may need this preference until we can move the logic into input plugins.

> - Additional functional event types such as quit, copy, minimize, show
> context menu etc if the platform-specific input plugin supports them.
> There are a bunch of Windows messages out there and X surely has its
> own. Control via preferences whether they go to the image or to the VM
> window itself, where it makes sense.
> - More input event types other than keyboard keys, such as scroll up
> with wheel, swipe right with 3 fingers, start dragging something out,
> dragged something in, dropped something etc. if the platform-specific
> input plugin supports them.

Yes. We need to capture all these inputs into virtual keycodes.

Regards .. Subbu



Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
In reply to this post by K K Subbu
Hi Subbu,

The Ctrl key is not an anachronism. Its original function, zeroing the upper two bits of the pressed ASCII character, is.

I don't think that close or drag and drop messages should be represented as virtual key codes. At least not as long as we call them key codes. ;-)

Linux does it exactly like I expect it: there is a virtual code for each possible supported hardware key. Including left Ctrl and right Ctrl. Not for uppercase letters. There are also codes for close, undo, mail, thumb button, red button etc, but not because there is such a function, but because some input devices have such keys.

Squeak is like an X Server in some ways. So it makes sense to have its own virtual codes and possibly allow remapping. But I don't believe that X hides the state of the Ctrl modifier from its clients.

If Squeak runs on an X Server, possibly with remapped keys, that's fine. X is the environment then and should send Squeak the keys however it wants.

My requirement still is that the image will be able to see when Ctrl is being held, if it happens that a keyboard with such a key is connected to the machine and one of the Ctrl keys is held down by the user, and the environment passes that information on to the VM. I see no reason to abstract/encapsulate away such kind of gesture in the plugins and thus hide it from Smalltalk.

In some older games, Ctrl is used as the fire button. If there is no way to see Ctrl, such game could not be implemented in Squeak. Or any application that wants to map Ctrl to a function.

Kind regards,
Jakob

K K Subbu <[hidden email]> schrieb am Di., 17. Dez. 2019, 08:03:
On 17/12/19 12:52 AM, Jakob Reschke wrote:
> Selectors are names and as such carry a meaning (hopefully). So if you
> code Ctrl+Q to mean #quit, then you make it fix for all possible
> applications. Ctrl+Q does not generally quit Windows applications,
> Alt+F4 does.

Please don't take the symbol literally. I just threw in #quit as a soft
keycode. Squeak is a virtual machine. It can define its own soft keys.
The question is - should these keys mimic hardware of the past or can we
reify them at a higher level today? If so, where should the physical
keys be converted into virtual keycodes - in the input plugin, in the VM
event handler or in the keyboard handler in the Image?

> So if this environment specific quit message is mapped to a quit event
> by the VM and then eventually to a #quit send by the image, then I would
> agree. But not to magically converting Ctrl+Q key events to anything
> else than "q was pressed with the Ctrl modifier", at least for key down
> and key up. The character might differ for key char (as in the copyright
> symbol example above).

Squeak Image, being a multi-platform, cannot make assumptions about
specific modifiers on a physical keyboard or specific input composition
methods on host OS. The input plugin, which is tied to a host, should
encapsulate such details.

> And for key up and key down, other systems have virtual key codes.
> Squeak should have them too (to finally abstract away the platform
> differences of the current key codes). But the VK for Ctrl+Q should be
> VK_Q (with modifier Ctrl), not VK_QUIT.

But CTRL+VK_Q simply passes on Ctrl handling into the Image and that
breaks encapsulation. The VM just offers two virtual input streams -
keyboard and motion inputs - and defines a list of virtual event codes
that the VM will report to the Image. The exact way in which these are
computed from the physical devices (keyboard, joystick, touchpad, mouse
etc) should be abstracted by input plugins (with a dynamically
configurable mapping - see XServer below).

> The Wikipedia page even says that this mapping of Ctrl+C and others to
> the control characters is an anachronism from the teletypewriter era. By
> all practical means today Ctrl is a modifier like Alt and the meaning is
> assigned by software, that is application or environment. To maintain
> flexibility, we should not deprive applications written in
> Squeak/Morphic from the opportunity to handle Ctrl themselves.

The statements are contradictory. If ctrl is anachronistic then why pass
it along to Squeak Image instead of factoring it out in the input plugin?

> Proposal:
> - Key up and key down events with virtual key codes that map actual
> keyboard keys, not functions, with all possible  modifiers, including
> Ctrl and Shift. > - No assignment of meaning to those by either VM, EventSensor, ... or
> Morphic.

This means that we are not abstracting input devices at all. Soft
keyboards on Android or iPad may not have ctrl or alt keys.

My proposal is to interpret modifiers within input plugins like the way
other multi-platform software handle them. For instance, Linux (another
multi-platform OS) defines these virtual codes that are mapped at the
input driver level :


https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h

XServer which runs on multiple OSes defines its own set of abstract
keycodes (keysyms) mapped by its input drivers and uses a tool to change
the mapping at any time:

  https://www.x.org/archive/X11R6.8.1/doc/xmodmap.1.html


> - Key Char (key stroke) event with environment-determined character in
> them. No modifiers at all! Uppercase characters should come in as such
> already, no need to look at Shift. If composed characters come in when
> they are finished they are taken as they are.

agreed. Makes sense.

> - The environment may send an ongoing composition as other events. It
> should be up to a preference whether something in Squeak handles these,
> to do the composition in Squeak itself.

We may need this preference until we can move the logic into input plugins.

> - Additional functional event types such as quit, copy, minimize, show
> context menu etc if the platform-specific input plugin supports them.
> There are a bunch of Windows messages out there and X surely has its
> own. Control via preferences whether they go to the image or to the VM
> window itself, where it makes sense.
> - More input event types other than keyboard keys, such as scroll up
> with wheel, swipe right with 3 fingers, start dragging something out,
> dragged something in, dropped something etc. if the platform-specific
> input plugin supports them.

Yes. We need to capture all these inputs into virtual keycodes.

Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

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

Stéphane Rollandin
> In some older games, Ctrl is used as the fire button. If there is no way
> to see Ctrl, such game could not be implemented in Squeak. Or any
> application that wants to map Ctrl to a function.

Exactly. And currently muO does just that, so hiding the Ctrl status
from the image would simply irreversibly break my own tools.

Please do not do that.

Stef

Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
I have no idea how you all read "no access to control-key pressed state anymore" out of my proposal. :-D

This discussion revolves entirely around the result of KeyboardEvent >> #keyCharacter and only around key-character events. No key down. No key up.

1) #isControlKeyPressed is still encoded an event's modifiers
2) There has never been a character event (aka. keystroke) for only hitting the CTRL "character".  You have to handle key down/up events for that.

Best,
Marcel

Am 18.12.2019 11:25:39 schrieb Stéphane Rollandin <[hidden email]>:

> In some older games, Ctrl is used as the fire button. If there is no way
> to see Ctrl, such game could not be implemented in Squeak. Or any
> application that wants to map Ctrl to a function.

Exactly. And currently muO does just that, so hiding the Ctrl status
from the image would simply irreversibly break my own tools.

Please do not do that.

Stef



Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
Sorry Marcel, I am discussing about Subbus proposal not about your change. I should have changed the subject line a few mails ago.

Marcel Taeumel <[hidden email]> schrieb am Mi., 18. Dez. 2019, 12:23:
I have no idea how you all read "no access to control-key pressed state anymore" out of my proposal. :-D

This discussion revolves entirely around the result of KeyboardEvent >> #keyCharacter and only around key-character events. No key down. No key up.

1) #isControlKeyPressed is still encoded an event's modifiers
2) There has never been a character event (aka. keystroke) for only hitting the CTRL "character".  You have to handle key down/up events for that.

Best,
Marcel

Am 18.12.2019 11:25:39 schrieb Stéphane Rollandin <[hidden email]>:

> In some older games, Ctrl is used as the fire button. If there is no way
> to see Ctrl, such game could not be implemented in Squeak. Or any
> application that wants to map Ctrl to a function.

Exactly. And currently muO does just that, so hiding the Ctrl status
from the image would simply irreversibly break my own tools.

Please do not do that.

Stef




Reply | Threaded
Open this post in threaded view
|

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

timrowledge
In reply to this post by Jakob Reschke


> On 2019-12-18, at 2:04 AM, Jakob Reschke <[hidden email]> wrote:
>
> Hi Subbu,
>
> 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.

> In some older games, Ctrl is used as the fire button. If there is no way to see Ctrl, such game could not be implemented in Squeak. Or any application that wants to map Ctrl to a function.

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


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Did you hear about Christopher Robin Hood? He stole from the rich to give to the Pooh



12