<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi all! :-)<div><br></div><div>I do not propose a loss of information, just a more consistent view on it with fewer special cases in the lower abstraction levels.</div><div><br></div><div>The goal is to provide a clean object representation for input events. So, we should simplify the data exchange between VM and image but keep it cross-platform compatible.</div><div><br></div><div>If anybody wants to implement a terminal-like application within Squeak, it is very simple to convert "anEvent controlKeyPressed and: [anEvent keyValue >= 64]" to that non-printable ascii range. However, I argue that this detail should not bleed into applications by default. And as long as VMs send those control characters for [ctrl]-combinations, EventSensor could unpack those to make typing [ctrl]+[0] behave like typing [ctrl]+[c].</div><div><br></div><div>I argue for a consistent representation of modifiers (ctrl, cmd/alt, shift, (opt), ...) and key characters. The following example is not possible at the moment but should:<br><br></div><div>MyMorph >> #handlesKeyboard: evt</div><div> ^ true</div><div>MyMorph >> #keyStroke: evt</div><div> (evt controlKeyPressed and: [evt keyCharacter = $c])</div><div> ifTrue: [self terminateApplication].</div><div><br></div><div>Why? Because there might be the requirement to "terminate on ctrl+c" for some application and it would be nice if one could just implement it that way. :-)</div><div><br></div><div>But maybe I am confusing "characters" and "keys" again. Happens way too quickly.</div><div><br></div><div>Maybe "ctrl" is no modifier at all? Sigh.</div><div><br></div><div>Best,</div><div>Marcel</div><div><br></div><div>P.S.: I want function keys, too! :-D</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 16.12.2019 07:13:04 schrieb K K Subbu <kksubbu.ml@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">On 15/12/19 6:02 PM, Jakob Reschke wrote:<br>> Did I get that wrong or are you really suggesting to make Ctrl <br>> unavailable as a modifier inside of Squeak?<br>> <br>> Many "normal" applications map Ctrl combinations. Most do so before they <br>> begin to map Alt. At least on Windows and Linux. Ctrl to them is what <br>> Cmd is to Mac, that's how I observed it.<br><br>Yes. My strawman proposal is to simplify code (VM and Image) through <br>separation of concerns and eliminate confusion across platforms. I don't <br>expect it to affect Squeak keyboard habits much [1]<br><br>VM input plugins will use modifiers like CTRL, SHIFT, CAPLOCK to decode <br>key presses and pass a "soft" keycode to the Image. For instance, when <br>you press Ctrl+C, the VM will decode this into 16r03 and pass it to the <br>Image. The Image will treat this as a "copy" command.Within the image, <br>non-printable codes will map directly to commands like cut (ctrl-x), <br>copy (ctrl-c), paste (ctrl-v), print (ctrl-p), open (ctrl-o), save <br>(ctrl-s), close (ctrl-w), quit (ctrl-q). ALT modifier is used to <br>interpret printable keys as commands like doit (alt-d), browse (alt-b) etc.<br><br>[1] Platforms often use modifier combinations to bypass apps, enter <br>accented characters or Unicode. Eg. CTRL+ALT on Linux, CMD+Option on <br>Mac) bypass applications and send commands directly to boot, host os or <br>the window manager. Other combinations like CTRL+SHIFT (Linux) or Option <br>(Mac) or ALT+Numeric+ (Windows) are used to enter any 4-nibble Unicode. <br>The Image should not have to deal with such low level detail. Let VM <br>input plugins handle these escapes gracefully.<br><br>Regards .. Subbu<br><br></div></blockquote></div>