<div dir="ltr"><div>Responsibility models aside,</div><div><br></div><div>Maybe we could have an object somewhere that contains a collection of possible keyboard event triggers and the action they should perform?</div><div><br></div><div>You know so if you want to add a new keyboard event you could just tell the object to add it to the collection and when you want to check if a combination should trigger something you just ask that object.</div><div><br></div><div>I think it would make sense from an usability standpoint since it would allow the user to define system wide events without touching system class methods or having to understand the chain of responsibility on detecting the input (and it would also allow you to define an erroneous trigger (accidentally of course) without making it so you can't use the keyboard anymore until you revert your change).</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 sáb, 19 dic 2020 a las 6:59, Luciano Notarfrancesco (<<a href="mailto:luchiano@gmail.com">luchiano@gmail.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"><div dir="auto">I think the hand is a metaphor for the actual users’ hand. Keyboard events also go through the hand. In my opinion this emphasises the tangibility of morphs, and having the option to create new kinds of hands enables experimentation that could lead to interesting places (as it happened in Squeak with MorphicWrappers, I made a new hand that implemented the “typing on air” thing).</div><div dir="auto"><br></div><div dir="auto">I’m not sure how all this would work with touch screens, tho... or what’s the idea for HandMorph in Morphic3. But I don’t like very much how we’ve been hooking events and implementing shortcuts in the event classes themselves because I need to be able to redefine that behaviour and it’s not all in one place, and it’s less flexible, and sometimes it’s not easy to find the code that I need to change to redefine the behaviour.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 19 Dec 2020 at 3:26 PM, Philip Bernhart <<a href="mailto:philip.bernhart@posteo.de" target="_blank">philip.bernhart@posteo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all.<br>
<br>
Luciano Notarfrancesco via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> writes:<br>
<br>
> Btw, I think the Morphic way to implement things like this is with hands.<br>
> User input should always go through the hand, and a particular kind of hand<br>
> can implement global shortcuts (for example to open a browser, alt-. to<br>
> open a debugger, alt-tab to switch between windows, opening of halos, etc).<br>
<br>
Interesting insight. But why the hand? A hand was always as far as I<br>
have seen in morphic the mouse pointer, which could have many instances.<br>
<br>
A hand in these days isn't necessarily a mouse pointer anymore, but<br>
could be a multitouch input event, a gesture or many remote users living<br>
on different machines.<br>
<br>
Wouldn't that be more the world in which the morph is running in as a<br>
world defines the global context, hence the word "world"?<br>
<br>
Philosphical question: do we even know at this point what is supposed to<br>
be "true" morphic after the decades adapting a lively system and porting<br>
it from original self to Squeak and then to the needs of each Squeak<br>
derived system?<br>
<br>
I for example only know morphic from the Self movie, where you could<br>
spawn morphs and adapt them according to your needs.<br>
<br>
My gut feeling is to do that which in turn simplifies the system and<br>
bears its own weight.<br>
<br>
<br>
Cheers,<br>
Philip<br>
<br>
-- <br>
</blockquote></div></div>
</blockquote></div>