[Cuis-dev] Update: Alt+Return as a full screen toggle shortcut

[Juan Vuletich]

I agree that we need to improve on this area. I don't have any specific 
plans on how do do this. But this discussion is interesting.

The current code evolved from Squeak's without ever thinking too much 
about it.

We need to think a good sequence for dispatching events. Right now, the 
most inner morph behind the hand (and on top of others) has the choice 
to process events before owner. See MorphicEvent >> 
dispatchWith:localPosition: . So, global keystrokes are handled before 
this. If the World or the Hand processed events before other morphs, all 
this could be easier to understand, extend, etc.

The Hand could be a good "semi global" place to dispatch events to the 
appropriate Morph. But if we do it by traversing the morph tree, the 
natural place to start is the World.

Let's keep thinking and discussing!

Thanks,

On 12/20/2020 2:02 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> I agree. I don’t want to change the way events work in Morphic and I 
> don’t want to add extra complexity, what I’m proposing is to put the 
> logic to handle a couple of global shortcuts in HandMorph or a 
> subclass instead of hardcode them in the event classes. I wouldn’t 
> even add preferences or anything like that that would add more 
> indirection.
>
>
> On Sat, 19 Dec 2020 at 10:36 PM, <ken.dickey at whidbey.com 
> <mailto:ken.dickey at whidbey.com>> wrote:
>
>     On 2020-12-19 05:48, Mauro Rizzi via Cuis-dev wrote:
>
>     > Maybe we could have an object somewhere that contains a
>     collection of
>     > possible keyboard event triggers and the action they should perform?
>
>     What happens now is that one uses mouseEnter and so forth with the
>     hand
>     position to determine keyboard focus.
>
>     I want context sensitive keys.  E.g. Smalltalk edit bindings vs
>     game-move bindings depending on what object has the keyboard
>     focus.  I
>     think of this as typical and expected.  Control is distributed.
>     Objects
>     decide.
>
>     To "steal" keys from the current keyboard focus object for overriding
>     keybindings would seem to require [1] a filter in the KeyboardEvent
>     class and [2] a protocol which can be overridden (like
>     #allowsKeyboardOverrides) so that an object which really wants keys
>     (think gaming) can get all of them and then if it does not want one
>     re-delegates it back to the "global" bindings.
>
>     Is the above better than what exists now?  Does it carry its own
>     weight?
>       [This is easy to implement, but adds code and is more complex,
>     and adds
>     a new protocol which everyone needs to be aware of.  There needs
>     to be a
>     strong motivator for change.]
>
>     Other options?
>
>     $0.02
>     -KenD
>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201220/cafe9e21/attachment.htm>