The Inbox: Kernel-mt.1287.mcz
Locked
12
12
 
|
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 ] ]. ! |
Re: The Inbox: Kernel-mt.1287.mcz
|
> This happens automatically when "duplicate (all) control and alt keys" or "swap control and alt keys" is enabled. Sigh. Best, Marcel
|
|
|
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 |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
K K Subbu <[hidden email]> schrieb am So., 15. Dez. 2019, 12:15:
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. |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
> 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 |
|
|
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 |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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
|
|
|
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 |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
> 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
|
|
|
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 |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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: 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... 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... |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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: |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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:
|
|
|
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 |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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
|
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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: |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
> 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 |
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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
|
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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:
|
Re: The Inbox: Kernel-mt.1287.mcz
|
|
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |