[Cuis-dev] Discoverability of morphic
pbpublist at gmail.com
Tue Jul 23 16:52:12 PDT 2019
tl;dr version: keyboard and mouse event handling are inextricably linked
unless/until VM changes are made.
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.
On Tue, Jul 23, 2019, 5:16 PM ken.dickey--- via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:
> 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,
> We could really use a good write up on complex/interesting UI events.
> I found the following in the squeak.org documentation:
> If you want your morph to get keyboard events, redefine the following
> 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'
> [https://github.com/Cuis-Smalltalk/Games/tree/master/Solitaire] for
> mouse event drag 'n drop code. Note 'of interest' in
> 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'
> [https://github.com/Cuis-Smalltalk/Learning-Cuis] 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'
> 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.
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cuis-dev