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

[Mauro Rizzi]

Hello Ken

You're right, I didn't think about the wasHandled: method before and it's a
better solution than the one I proposed (assuming the methods
isFindClassShortcut and isCloseWindowShortcut and Franco's
isFullScreenShortcut would be moved into handleKeyEvent and the processKey*
ones would have their return removed).

It would look something like:

vvv============vvv
KeyBoardEvent>>

sentTo: aMorph localPosition: positionInAMorph

        "Dispatch the receiver into anObject"

   type == #keystroke ifTrue: [
         aMorph
                 processKeystroke: self
                 localPosition: positionInAMorph ].
   type == #keyDown ifTrue: [
         aMorph
                processKeyDown: self
                localPosition: positionInAMorph ].
   type == #keyUp ifTrue: [
         aMorph
                processKeyUp: self
                localPosition: positionInAMorph ].

    (self wasHandled)
         ifTrue: [^aMorph] "done"
         ifFalse: [<globaldefaultKeyHandler> handleKeyEvent: self]


^^^============^^^
  "Inside globaldefaultKeyHandler, of course if someone thinks this object
shouldn't exist you could just put it's content on the ifFalse closure.
Also technically the ifFalse is unnecessary, but it does provide a lot of
clarity."
handleKeyEvent: aKeyboardEvent

        aKeyboardEvent isFindClassShortcut
                ifTrue: [ ^ BrowserWindow findClass].
        aKeyboardEvent isCloseWindowShortcut
                ifTrue: [ ^ aKeyboardEvent closeCurrentWindowOf: aMorph
        aKeyboardEvent isFullScreenShortcut
                ifTrue: [ ^ Display toggleFullScreen ]

^^^============^^^

We would have to refactor the current senders of wasHandled: to take into
account this change.

Thinking on the readability of this method and it might be a bit hard to
follow the wasHandled method call for someone who is first discovering it,
since they potentially might not understand how keyboardEvent knows the
event was handled.

I do approve of the idea of having global keystrokes be in a separate
object than the standard keyboardEvent, I think it would give clarity to
the chain of responsibility if it goes into the morph and then into a
global keystroke handler object.

Thinking about it from an usability standpoint using franco's full screen
shorcut (alt + enter) we would have to (with both of the proposed
implementations) make the isFullScreenShortcut check on the keyboardEvent
inside the target morph to avoid processing the input at the morph level
and marking it as handled.

What I mean with this is that all morphs would be responsible of knowing
what inputs they should ignore because the keystrokes that we want to
capture for system events would also be considered valid inside the morph
and would be executed.

For example if you press shift enter while writing in a method editor the
innerTextPane will happily process the input, put the newline into the pane
and mark the event as handled, following that the keyboardEvent will say
"ah, well that is done with then, moving on" and the findClass dialogue
won't pop up, to avoid this you'd have to check whether the current
keystroke is one of the system ones inside the morph's execution chain.

While I do like your implementation significantly more I think the one I
recommended earlier gets around this issue. Since it becomes something
optional, your morph can decide if it wants to override certain keystrokes
or not but if you don't implement the method shouldOverride (Note: this is
a bad name for this method) then you go back to the current behaviour.

Basically one option gives the morph the choice to tell you if it wants to
override or not. The other one gives the morph the responsibility of
telling you whether you should override or not.

And I still feel keyboardEvent should have a hierarchy of the 3 types of
keyboard events rather than having a type instance variable.

I just want to clarify I quite enjoy writing walls of text and this is
intended as constructive brainstorming. I'm sorry if it comes out as
anything but.

Cheers!
*Mauro Rizzi*

El dom, 20 dic 2020 a las 20:54, <ken.dickey at whidbey.com> escribió:

> On 2020-12-20 21:25, Mauro Rizzi wrote:
>
> ..
> > shouldOverride := aMorph shouldOverride: self
>
> I am suggesting that if the Morph processes the keystroke, it _has_
> overriden and _does NOT need_ a #shouldOverride method.
>
> So
> vvv============vvv
> KeyBoardEvent>>
>
> sentTo: aMorph localPosition: positionInAMorph
>
>         "Dispatch the receiver into anObject"
>
>    type == #keystroke ifTrue: [
>         self isFindClassShortcut
>                 ifTrue: [ ^ BrowserWindow findClass].
>         self isCloseWindowShortcut
>                 ifTrue: [ ^ self closeCurrentWindowOf: aMorph ].
>         ^ aMorph processKeystroke: self
>                  localPosition: positionInAMorph ].
>    type == #keyDown ifTrue: [
>                 ^ aMorph
>                         processKeyDown: self
>                         localPosition: positionInAMorph ].
>    type == #keyUp ifTrue: [
>                 ^ aMorph
>                         processKeyUp: self
>                         localPosition: positionInAMorph ].
>
>     (self wasHandled)
>          ifTrue: [^aMorph] "done"
>          ifFalse: [<globaldefaultKeyHandler> handleKeyEvent: self]
>
>
> ^^^============^^^
>
> Note: I am not an expert here.  Just a guess..
>
> Prototype is best.
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201220/36372f3b/attachment-0001.htm>