[Cuis-dev] Update: Alt+Return as a full screen toggle shortcut
Mauro Rizzi
mrizzi at fi.uba.ar
Sun Dec 20 13:25:01 PST 2020
Hello Ken,
I'm sorry if my last email was hard to follow, I tried to think how the
idea would fit into the method and actually changed it a bit. My original
idea was for the processKey* methods to return the signal (i'm using signal
as to not just say a boolean) of whether they override system globals or
not, after which you would use that signal to know if you should check if
the event triggers a system wide action or not. Now i'm thinking that
instead of changing what the processKey* methods have to return we can just
ask the morph if it should override the global hotkeys.
As I understand it right now, all the keyboard inputs go through the
sentTo:localPosition method in the keyboardEvent class.
What I suggest now is that maybe that method should look something like
this:
sentTo: aMorph localPosition: positionInAMorph
| shouldOverride |
shouldOverride := aMorph shouldOverride: self
shouldOverride ifFalse: [
type == #keystroke ifTrue :[
self isFindClassShortcut
ifTrue: [ ^ BrowserWindow findClass].
self isCloseWindowShortcut
ifTrue: [ ^ self closeCurrentWindowOf: aMorph ].
self isFullScreenShortcut
ifTrue: [^ Display toggleFullScreen ]]].
type == #keystroke ifTrue: [
^ aMorph
processKeystroke: self
localPosition: positionInAMorph].
type == #keyDown ifTrue: [
^ aMorph
processKeyDown: self
localPosition: positionInAMorph ].
type == #keyUp ifTrue: [
^ aMorph
processKeyUp: self
localPosition: positionInAMorph ].
(editor's note: why is the type check not replaced by polymorphism?)
^ super
sentTo: aMorph
localPosition: positionInAMorph.
And then you implement the shouldOverride instance method in the Morph
class (the generic one) as follows:
shouldOverride: aKeyboardEvent
^false
And if you want your new morph to override a specific keyboard event you
just implement the shouldOverride: method and either return True if you
want your morph to prevent the user from using any global keybindings or
you just check the nature of the keyboardEvent (probably through the
methods implemented in the keyboardEvent class that are currently
categorized as testing) to see if you want to intercept that specific event.
Of course this is not a final solution, but given the current
implementation it might be an easy compromise to let people decide if their
morph can override system global keybindings or not.
For what I understood of your understanding (writing that felt weird) of my
previous email follows a different route that would require to change all
the processKeystroke implementations on the system to tell the
keyboardEvent it wasn't handled if it doesn't want to override the system
wide events. And i'm not sure what consequences changing the use case of
the instance variable wasHandled would have.
I'm also unsure why the UserInputEvent has a "type" instance variable,
couldn't that be better represented through polymorphism?
Cheers!
*Mauro Rizzi*
El dom, 20 dic 2020 a las 15:40, <ken.dickey at whidbey.com> escribió:
> On 2020-12-20 07:36, Mauro Rizzi via Cuis-dev wrote:
>
> > 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.
>
> That is basically how the keyboard events are handled now by the
> Morph>>processKey*:localPosition: methods.
>
> Note
>
> aKeyboardEvent wasHandled: true.
>
> So I believe what you are asking for is that in the 'false' case, the
> handler would use a global default action, which could be set up in
> World/Hand/??.
>
> In this case, handling the Keyboard event in a local Morph would
> naturally override the global default with no code changes except for
> the check for #wasHandled in (perhaps)
> KeyboardEvent>>sentTo:localPosition: .
>
> Am I understanding you correctly?
>
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201220/1d7e36b9/attachment.htm>
More information about the Cuis-dev
mailing list