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

[Mauro Rizzi]

I'm thinking without concern about responsabilitiy models here,

Maybe we could we make it so the keyboard event first passes the event to
the selected morph, and the morph has the responsibility to return a
boolean or some other indication of whether the morph overrides the global
keybindings for that event or not and then depending on the response the
keyboardEvent handler either stops the chain or continues.

So it would be something like:

KeyboardEvent -> SelectedMorph -> KeyboardEvent -> (ifNotOverriden) ->
global shortcut check

-> (ifOverriden) -> end execution chain.

So you'd have a method in the Morph class (instance side) that always
returns the signal to not override but can be implemented in the Morph that
needs to override to return the corresponding signal.

I think this could be done without refactoring half the system.

*Mauro Rizzi*


El dom, 20 dic 2020 a las 11:24, Juan Vuletich (<juan at jvuletich.org>)
escribió:

> 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> 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 Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://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/cc4090fc/attachment-0001.htm>