<div dir="auto">Hi Marcel, <div dir="auto"><br></div><div dir="auto">Let me reply to you as the topic opener for a change ;-)</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank" rel="noreferrer">marcel.taeumel@hpi.de</a>> schrieb am Mo., 16. Dez. 2019, 11:24:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_-9203738557363030267m_-5929088678591706159__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:#000000"><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></blockquote></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_-9203738557363030267m_-5929088678591706159__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:#000000"><div><br></div><div>But maybe I am confusing "characters" and "keys" again. Happens way too quickly.</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">If things went my way, you would handle the Ctrl+C gesture as a key down (or up) event. Key char/stroke is for text input (mostly). For example, it will repeat (at the environment's discretion) if you hold the keys down. To be able to handle Ctrl+C as key down/up, there should be a platform-independent way to represent "the key C". Today we get the environment/platform-specific key code (correct?), and instead it should be a Squeak-defined unified code (for a keyboard button in this case).</div><div dir="auto"><br></div><div dir="auto">If I understand Subbu correctly after re-reading the thread, he would like that you handle/implement a #terminate message instead. Ctrl+C is mapped to #terminate by an input plugin in this scenario. And Subbu seems to count this #terminate among the "virtual key codes". The mapping in the plugin would be configurable, like with xmodmap for X Server. @Subbu please correct me if I still got you wrong.</div><div dir="auto"><br></div><div dir="auto">I argue that such high-level key mapping should be done in the image and on top of unified virtual key codes. Plugins are harder to change. Moreover key mapping should work application-specific and multiple applications can run in the same Squeak image. In particular if it is a "developer image". I imagine this would be more difficult if the mapping happens in a plugin. However, I agree that such general mapping, if implemented, should happen outside of (or rather before) Morphic.</div><div dir="auto"><br></div><div dir="auto">Finally in my opinion we should not lose the possibility of letting an application handle a keyboard as it is, with at last Ctrl, Alt, Shift and their Mac equivalents, and possibly other modifiers. Hence no enforced/required mapping of "low level key combinations" to "high level messages", only a mapping of "platform specific key codes" to "unified key codes for Squeak".</div><div dir="auto"><br></div><div dir="auto">Maybe we could have both approaches at the same time. And maybe it does make sense to rename the modifiers to get around the Cmd vs Ctrl (or Alt?) problem. <span style="font-family:sans-serif">The mouse buttons are already called red, yellow, blue...</span> And which one is which is then really something for the plugins.</div><div dir="auto"><br></div><div dir="auto">Kind regards</div><div dir="auto">Jakob</div></div>