[squeak-dev] A suggestion: allowing ctrl+drag in morphs

Marcel Taeumel marcel.taeumel at hpi.de
Fri May 11 13:03:10 UTC 2018


Hi Stef,

First, let me acknowledge that this is kind of a regression. :-)

Now, what is the situation here:

1) Morphs used to be in control by overwriting #handleMouseDown: to avoid the invocation of the meta menu. I changed this by moving the code to PasteUpMorph >> #tryInvokeMetaMenu:. My intention is still to increase the robustness of the system in the face of erroneous morphs.

2) The check for #wantsMetaMenu is not sufficient in this case because you have to control the entire ownership of a morph to avoid the meta menu. At least the (Morphic) world will give you its meta menu.

3) It would be nice to only invoke the meta menu for CTRL+YELLOW so that CTRL+RED could be used for something different. This is not possible due to automatic conversions in the VM. So, at the moment the code fires on CTRL+ANYTHING. This is bad because it wastes user-input gestures as you discovered in your code.

4) The preference "cmdGesturesEnabled" is rather misleading. It looks like we need a "morphicMetaMenuEnabled" preference, which works system wide but can be disabled for muO or other applications.

5) If we, as you proposed, would add code that allows individual morphs to bypass this generic development tool (i.e. the meta menu), we would decrease the robustness of the system again. That's why I disagree with your change.

***

The bottom line is that you should disable the command gestures via "Preferences disable: #cmdGesturesEnabled". I think we should split up this preference into "morphicHaloEnabled" and "morphicMetaMenuEnabled". By disabling #cmdGesturesEnabled, your morphs need to open their halo manually such as via #mouseDown: calling #invokeHaloOrMove:. :-)

If you have more questions, keep on asking. The meta menu is a dev tool, which must work under any circumstances.

Further readings:
http://forum.world.st/Please-Review-Map-CTRL-red-to-CTRL-yellow-and-CMD-red-to-CMD-blue-td4913716.html [http://forum.world.st/Please-Review-Map-CTRL-red-to-CTRL-yellow-and-CMD-red-to-CMD-blue-td4913716.html]
http://forum.world.st/How-to-yellow-click-with-two-buttons-without-changing-mouse-settings-tp5074670p5074775.html [http://forum.world.st/How-to-yellow-click-with-two-buttons-without-changing-mouse-settings-tp5074670p5074775.html]
http://forum.world.st/How-to-yellow-click-with-two-buttons-without-changing-mouse-settings-tp5074670p5075027.html [http://forum.world.st/How-to-yellow-click-with-two-buttons-without-changing-mouse-settings-tp5074670p5075027.html]

Sorry for any inconveniences...

Best,
Marcel
Am 11.05.2018 12:17:36 schrieb Stéphane Rollandin <lecteur at zogotounga.net>:
> The actual issue is still RED -> YELLOW. That's why the meta menu is
> invoked in the first place. Your suggestion/fix is a rather unstable
> workaround. :-/ Sure, you can make it work for a single application.
> Yet, it breaks in the general sense.


I do not understand what you mean by unstable. What is wrong with
testing that the CTRL key is pressed during a mouseMove:?

I do not understand either what you mean by "work for a single
application". My code lets each Morph subclass decides if it wants the
meta menu or not. It doesn't change anything to the behavior of morphs
that do not explicitely reject it. So what is it breaking?

I have had this working for years in muO. The reason I am proposing some
code now is that I just realized, in the process or porting muO to
Squeak 6, that it has become much simpler to implement now, thanks to
your refactoring BTW.

Please have a look at the image I just uploaded at
http://zogotounga.net/swap/CtrlDrag.zip and see by yourself if there is
anything unstable there.

Again, what I propose is just and only to be able to escape the meta
menu mechanism. What is the justification for not allowing a way to bail
out of it?


Best,

Stef

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180511/04da68a7/attachment.html>


More information about the Squeak-dev mailing list