<div dir="ltr">
<div>Hello Ken,</div><div><br></div><div>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.<br></div><div><br></div><div>As I understand it right now, all the keyboard inputs go through the sentTo:localPosition method in the keyboardEvent class.</div><div><br></div><div>What I suggest now is that maybe that method should look something like this:</div><div><br></div><div>sentTo: aMorph localPosition: positionInAMorph</div><div><br></div><div>   
    

| shouldOverride |<br><br></div><div>
    

shouldOverride := aMorph shouldOverride: self</div><div><br></div><div>
    

shouldOverride ifFalse: [</div><div>
    


    

type == #keystroke ifTrue :[<br></div><div>
    
    

self isFindClassShortcut <br>                     
    


    


    

ifTrue: [ ^ BrowserWindow findClass].<br>         
    


    

self isCloseWindowShortcut<br>                    
    


    


    

ifTrue: [ ^ self closeCurrentWindowOf: aMorph ].<br>              
    


    

self isFullScreenShortcut<br>                     
    


    


    

ifTrue: [^ Display toggleFullScreen ]]].<br></div><div><br></div><div>
    

type == #keystroke ifTrue: [</div><div>
    


    

^ aMorph<br>                      
    

    



    

processKeystroke: self<br>                        
    
    




    

localPosition: positionInAMorph].</div><div><br></div><div>
    

type == #keyDown ifTrue: [<br>            
    


    

^ aMorph<br>                      
    


    


    

processKeyDown: self<br>                  
    


    


    

localPosition: positionInAMorph ].</div><div><br></div><div>
    

type == #keyUp ifTrue: [ <br>             
    


    

^ aMorph<br>                      
    

    


    


processKeyUp: self<br>                    
    

    


    


localPosition: positionInAMorph ].</div><div><br></div><div>(editor's note: why is the type check not replaced by polymorphism?)<br></div><div><br></div><div>
    

^ super<br>               
    


    

sentTo: aMorph<br>    
    

localPosition: positionInAMorph.</div><div><br></div><div>And then you implement the shouldOverride 
instance 

 method in the Morph class (the generic one) as follows:</div><div><br></div><div>    shouldOverride: aKeyboardEvent</div><div><br></div><div>    
    

^false</div><div><br></div><div></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div></div><div>I'm also unsure why the UserInputEvent has a "type" instance variable, couldn't that be better represented through polymorphism?</div><div><br></div><div>Cheers!</div><div><b>Mauro Rizzi</b><br></div>

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El dom, 20 dic 2020 a las 15:40, <<a href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-12-20 07:36, Mauro Rizzi via Cuis-dev wrote:<br>
<br>
> Maybe we could we make it so the keyboard event first passes the event <br>
> to the selected morph, and the morph has the responsibility to return a <br>
> boolean or some other indication of whether the morph overrides the <br>
> global keybindings for that event or not and then depending on the <br>
> response the keyboardEvent handler either stops the chain or continues.<br>
<br>
That is basically how the keyboard events are handled now by the <br>
Morph>>processKey*:localPosition: methods.<br>
<br>
Note<br>
<br>
   aKeyboardEvent wasHandled: true.<br>
<br>
So I believe what you are asking for is that in the 'false' case, the <br>
handler would use a global default action, which could be set up in <br>
World/Hand/??.<br>
<br>
In this case, handling the Keyboard event in a local Morph would <br>
naturally override the global default with no code changes except for <br>
the check for #wasHandled in (perhaps) <br>
KeyboardEvent>>sentTo:localPosition: .<br>
<br>
Am I understanding you correctly?<br>
<br>
-KenD<br>
</blockquote></div>