<div dir="auto"><div dir="auto">tl;dr version: keyboard and mouse event handling are inextricably linked unless/until VM changes are made.</div><div dir="auto"> </div><div>Ken gives a good overview of the state of things from the Cuis perspective but also keep in mind that Cuis inherits baggage from Morphic, Squeak and the VM. Squeak was developed in the 1990's primarily on Macs with a 1980's UI sensibility and most of the current input event handling issues stem from this. Unless/until the VM allows for sending something closer to unpreprocessed mouse/keyboard events, several things cannot be fixed/simplified and the expressiveness of UIs in Morphic will be limited. If we had a full complement of truly separate and unprocessed input events by device type from the VM, it would be possible to have a much nicer, more performant, input event system.</div><div dir="auto"> </div><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019, 5:16 PM ken.dickey--- via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-07-20 23:28, Philip Bernhart via Cuis-dev wrote: > where should we put the information regarding of how to > get stuff done with morphic? Sorry if someone else has already answered this. I can only give you my take on things. First, this stuff is not well documented (an exercise for the user, sigh). We could really use a good write up on complex/interesting UI events. I found the following in the <a href="http://squeak.org" rel="noreferrer noreferrer" target="_blank">squeak.org</a> documentation: <a href="http://wiki.squeak.org/squeak/2415" rel="noreferrer noreferrer" target="_blank">http://wiki.squeak.org/squeak/2415</a> ===================vvvv If you want your morph to get keyboard events, redefine the following methods MyMorph>>handlesKeyboard: evt ^ true MyMorph>>mouseEnter: evt evt hand keyboardFocus: self MyMorph>>mouseLeave: evt evt hand releaseKeyboardFocus: self keyDown: anEvent "Handle a key down event. ." anEvent keyCharacter = $a ifTrue: [self doSomething]. anEvent keyCharacter = $q ifTrue: [self doAnotherOne] ===================^^^^ So, yes. One can use #mouseEnter: to get the keyboard focus. > I think it should not take a couple of hours of digging > in the class hierarchy to find out > "why does my morph not receive keystroke events > when I already declared that it handlesKeyboard events?!" I also find the event system confusing to use. Look at the code in 'Morphic-Games-Solitaire' [<a href="https://github.com/Cuis-Smalltalk/Games/tree/master/Solitaire" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Games/tree/master/Solitaire</a>] for mouse event drag 'n drop code. Note 'of interest' in 'Learning-Cuis/PackageRef.md' [<a href="https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/PackageRef.md" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/PackageRef.md</a>] Part of the problem is distinguishing click and double-click events where one has to wait for a timeout. Also, keyboard focus is a topic in its own when it comes to creating panels with tab linked fields. One does not always want the keyboard focus just because the mouse is over. Mouse and Keyboard are frequently independent. Your choices are many, depending on your UI usage. I think the community would welcome some sample app/code/package, perhaps in 'Learning Cuis' [<a href="https://github.com/Cuis-Smalltalk/Learning-Cuis" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Learning-Cuis</a>] showing some of the options. Dragging and dropping a morph, tab-next fill-in text fields, change morph shape by drag, i.e. basic UI interaction choices. Or perhaps a MorphicFAQ.md file in 'Cuis-Smalltalk-Dev/Documentation' [<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation</a>] with questions you had and answers you found. Or, if the questions are few enough, sample code in the Terse Guide would be really cool. So you see the problem. Even as we try to document things in the Cuis world, there are a number of choices and places to find things. How to tie this together to make things easier to find?? Good questions. Please help with the answers. Thanks, -KenD -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div></div>