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