<div dir="auto">@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.<div dir="auto"><br></div><div dir="auto">Tl;dr: proposal section at the bottom.</div><div dir="auto"><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Is F1 #showHelp or #goToFirstPage?</div><div dir="auto">Is F10 #openApplicationMenu, #decreaseFrameRate or #showHighScore?</div><div dir="auto">Is Esc #escape or #showYellowKeyMenu?</div><div dir="auto">Is Ctrl+A #selectAll or #moveToBeginning?</div><div dir="auto"><div dir="auto"><br></div><div dir="auto">If the environment<span style="font-family:sans-serif"> (OS or window manager or input/output system)</span> 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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Proposal:</div><div dir="auto">- 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.</div><div dir="auto">- No assignment of meaning to those by either VM, EventSensor, ... or Morphic.</div><div dir="auto">- 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.</div><div dir="auto">- 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.</div><div dir="auto">- 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. </div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">Sorry for the long text and probably repeating myself several times.</div><div dir="auto"><br></div><div dir="auto">Kind regards</div><div dir="auto">Jakob</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">K K Subbu <<a href="mailto:kksubbu.ml@gmail.com" rel="noreferrer noreferrer" target="_blank">kksubbu.ml@gmail.com</a>> schrieb am Mo., 16. Dez. 2019, 16:50:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16/12/19 8:24 PM, Marcel Taeumel wrote:<br>
> The representation of such user-input events is not necessarily specific <br>
> to Morphic, only that #keyStroke: interface is. In the long term, it <br>
> would be nice to move "UserInputEvent" etc. out of Morphic into its own <br>
> base package. This is a matter of finding a consistent, object-oriented <br>
> representation for user-input events. :-)<br>
<br>
Right. key is a physical button while keycode is what is generated by <br>
keyboard driver. keycode is a low-level numeric code. Morphic should <br>
only deal with objects like character or selector.<br>
<br>
> it appears here, CTRL does not only modify a key (character) but <br>
> actually *modifies* a key (character). :-D Then, again, SHIFT does this, <br>
> too. Hmmm...<br>
<br>
I had to read that a couple of times to understand it ;-). CTRL modifies <br>
a keycode not a character. It was introduced to accommodate the <br>
limitations of a physical keyboard. This is why soft keyboards (like the <br>
ones on smartphones) don't need one.<br>
<br>
  <a href="https://en.wikipedia.org/wiki/Control_key" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Control_key</a><br>
  <a href="https://en.wikipedia.org/wiki/Alt_key" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Alt_key</a><br>
<br>
Regards .. Subbu<br>
<br><br>
</blockquote></div>
</div></div></div>