@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 <kksubbu.ml at gmail.com> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191216/57928e25/attachment.html>