Hi Nicolas, hi all!

I documented the status quo here:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456 [https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456]


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 <kksubbu.ml at gmail.com>:
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191217/125ad93d/attachment-0001.html>