<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Nicolas, hi all!<div><br></div><div>I documented the status quo here:</div><div><span style="font-size: 10pt"><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456">https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456</a></span><br></div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 17.12.2019 08:03:59 schrieb K K Subbu <kksubbu.ml@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">On 17/12/19 12:52 AM, Jakob Reschke wrote:<br>> Selectors are names and as such carry a meaning (hopefully). So if you <br>> code Ctrl+Q to mean #quit, then you make it fix for all possible <br>> applications. Ctrl+Q does not generally quit Windows applications, <br>> Alt+F4 does.<br><br>Please don't take the symbol literally. I just threw in #quit as a soft <br>keycode. Squeak is a virtual machine. It can define its own soft keys. <br>The question is - should these keys mimic hardware of the past or can we <br>reify them at a higher level today? If so, where should the physical <br>keys be converted into virtual keycodes - in the input plugin, in the VM <br>event handler or in the keyboard handler in the Image?<br><br>> So if this environment specific quit message is mapped to a quit event <br>> by the VM and then eventually to a #quit send by the image, then I would <br>> agree. But not to magically converting Ctrl+Q key events to anything <br>> else than "q was pressed with the Ctrl modifier", at least for key down <br>> and key up. The character might differ for key char (as in the copyright <br>> symbol example above).<br><br>Squeak Image, being a multi-platform, cannot make assumptions about <br>specific modifiers on a physical keyboard or specific input composition <br>methods on host OS. The input plugin, which is tied to a host, should <br>encapsulate such details.<br><br>> And for key up and key down, other systems have virtual key codes. <br>> Squeak should have them too (to finally abstract away the platform <br>> differences of the current key codes). But the VK for Ctrl+Q should be <br>> VK_Q (with modifier Ctrl), not VK_QUIT.<br><br>But CTRL+VK_Q simply passes on Ctrl handling into the Image and that <br>breaks encapsulation. The VM just offers two virtual input streams - <br>keyboard and motion inputs - and defines a list of virtual event codes <br>that the VM will report to the Image. The exact way in which these are <br>computed from the physical devices (keyboard, joystick, touchpad, mouse <br>etc) should be abstracted by input plugins (with a dynamically <br>configurable mapping - see XServer below).<br><br>> The Wikipedia page even says that this mapping of Ctrl+C and others to <br>> the control characters is an anachronism from the teletypewriter era. By <br>> all practical means today Ctrl is a modifier like Alt and the meaning is <br>> assigned by software, that is application or environment. To maintain <br>> flexibility, we should not deprive applications written in <br>> Squeak/Morphic from the opportunity to handle Ctrl themselves.<br><br>The statements are contradictory. If ctrl is anachronistic then why pass <br>it along to Squeak Image instead of factoring it out in the input plugin?<br><br>> Proposal:<br>> - Key up and key down events with virtual key codes that map actual <br>> keyboard keys, not functions, with all possible modifiers, including <br>> Ctrl and Shift. > - No assignment of meaning to those by either VM, EventSensor, ... or<br>> Morphic.<br><br>This means that we are not abstracting input devices at all. Soft <br>keyboards on Android or iPad may not have ctrl or alt keys.<br><br>My proposal is to interpret modifiers within input plugins like the way <br>other multi-platform software handle them. For instance, Linux (another <br>multi-platform OS) defines these virtual codes that are mapped at the <br>input driver level :<br><br> <br>https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h<br><br>XServer which runs on multiple OSes defines its own set of abstract <br>keycodes (keysyms) mapped by its input drivers and uses a tool to change <br>the mapping at any time:<br><br> https://www.x.org/archive/X11R6.8.1/doc/xmodmap.1.html<br><br><br>> - Key Char (key stroke) event with environment-determined character in <br>> them. No modifiers at all! Uppercase characters should come in as such <br>> already, no need to look at Shift. If composed characters come in when <br>> they are finished they are taken as they are.<br><br>agreed. Makes sense.<br><br>> - The environment may send an ongoing composition as other events. It <br>> should be up to a preference whether something in Squeak handles these, <br>> to do the composition in Squeak itself.<br><br>We may need this preference until we can move the logic into input plugins.<br><br>> - Additional functional event types such as quit, copy, minimize, show <br>> context menu etc if the platform-specific input plugin supports them. <br>> There are a bunch of Windows messages out there and X surely has its <br>> own. Control via preferences whether they go to the image or to the VM <br>> window itself, where it makes sense.<br>> - More input event types other than keyboard keys, such as scroll up <br>> with wheel, swipe right with 3 fingers, start dragging something out, <br>> dragged something in, dropped something etc. if the platform-specific <br>> input plugin supports them.<br><br>Yes. We need to capture all these inputs into virtual keycodes.<br><br>Regards .. Subbu<br><br></div></blockquote></div>