Smalltalk › Squeak › Squeak - Dev

A suggestion: allowing ctrl+drag in morphs

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Stéphane Rollandin

A suggestion: allowing ctrl+drag in morphs

Currently, it is not straightforward to define a ctrl+drag behavior for
a morph when preference cmdGesturesEnabled is true (the case by
default), because mouseDown when the control key is pressed opens a menu.

I did implement this for muO though.

In 6.0, it is very easy to do; we just need to add a line in the
following method:

-----------------------

PasteUpMorph>>tryInvokeMetaMenu: anEvent

| innerMost target |
Preferences cmdGesturesEnabled ifFalse: [^ self].
Preferences eToyFriendly ifTrue: [^ self].

innerMost := (self morphsAt: anEvent position unlocked: true) first.

innerMost honorsCtrlMetaMenu ifFalse: [^ self]. "<=== here"

"Traverse the owner chain if some morph does not want to show its meta
menu."
target := innerMost.
[target isNil or: [target wantsMetaMenu]] whileFalse: [target := target
owner].
target ifNil: [^ self].

target invokeMetaMenu: anEvent.
anEvent ignore.

------------------------

... with Morph>>#honorsCtrlMetaMenu returning true (so the current
behavior does not change), overriden to false by any morph wanting to
implement a ctrl+drag behavior.

Stef

marcel.taeumel

Re: A suggestion: allowing ctrl+drag in morphs

Hmm... it does not seem right to add such a side-effect into "tryInvokeMetaMenu". The actual issue is that CTRL+RED never reaches the image but is transformed to CTRL+YELLOW in the VM, which is related to single-button-mouse support.

At the moment, there is no way to make a morph react to CTRL+RED(drag) accordingly. :-(

Best,

Marcel

Am 10.05.2018 15:49:09 schrieb Stéphane Rollandin <[hidden email]>:
Currently, it is not straightforward to define a ctrl+drag behavior for
a morph when preference cmdGesturesEnabled is true (the case by
default), because mouseDown when the control key is pressed opens a menu.

I did implement this for muO though.

In 6.0, it is very easy to do; we just need to add a line in the
following method:

-----------------------

PasteUpMorph>>tryInvokeMetaMenu: anEvent

| innerMost target |
Preferences cmdGesturesEnabled ifFalse: [^ self].
Preferences eToyFriendly ifTrue: [^ self].

innerMost := (self morphsAt: anEvent position unlocked: true) first.

innerMost honorsCtrlMetaMenu ifFalse: [^ self]. "<===>

"Traverse the owner chain if some morph does not want to show its meta
menu."
target := innerMost.
[target isNil or: [target wantsMetaMenu]] whileFalse: [target := target
owner].
target ifNil: [^ self].

target invokeMetaMenu: anEvent.
anEvent ignore.

------------------------

... with Morph>>#honorsCtrlMetaMenu returning true (so the current
behavior does not change), overriden to false by any morph wanting to
implement a ctrl+drag behavior.

Stef

Stéphane Rollandin

Re: A suggestion: allowing ctrl+drag in morphs

> Hmm... it does not seem right to add such a side-effect into
> "tryInvokeMetaMenu". The actual issue is that CTRL+RED never reaches the
> image but is transformed to CTRL+YELLOW in the VM, which is related to
> single-button-mouse support.
>
> At the moment, there is no way to make a morph react to CTRL+RED(drag)
> accordingly. :-(

You missed the part where I say I have it work in muO... I just test for
controlKeyPressed in mouseMove and that's it. But I first need to
inhinbit the meta menu, and this is what my suggested patch allows.

So, I do not see this as a side-effect to tryInvokeMetaMenu, but simply
as a hook allowing me to bypass the meta menu mechanism. I really don't
mind if you put that hook anywhere else, but it is useful, because it
allows a drag gesture to happen while CTRL is down. That's enough for
me, and that's enough to have CTRL+DRAG gestures by testing for
controlKeyPressed in mouseDown events.

If you want to see it in action I can send you an example image.

Best,

Stef

Stéphane Rollandin

Re: A suggestion: allowing ctrl+drag in morphs

> So, I do not see this as a side-effect to tryInvokeMetaMenu, but simply
> as a hook allowing me to bypass the meta menu mechanism. I really don't
> mind if you put that hook anywhere else, but it is useful, because it
> allows a drag gesture to happen while CTRL is down. That's enough for
> me, and that's enough to have CTRL+DRAG gestures by testing for
> controlKeyPressed in mouseDown events.

The last part should read:

by testing for controlKeyPressed in mouseMove: events.

Stef

marcel.taeumel

Re: A suggestion: allowing ctrl+drag in morphs

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.

Best,

Marcel

Am 11.05.2018 10:44:42 schrieb Stéphane Rollandin <[hidden email]>:
> So, I do not see this as a side-effect to tryInvokeMetaMenu, but simply
> as a hook allowing me to bypass the meta menu mechanism. I really don't
> mind if you put that hook anywhere else, but it is useful, because it
> allows a drag gesture to happen while CTRL is down. That's enough for
> me, and that's enough to have CTRL+DRAG gestures by testing for
> controlKeyPressed in mouseDown events.

The last part should read:

by testing for controlKeyPressed in mouseMove: events.

Stef

Stéphane Rollandin

Re: A suggestion: allowing ctrl+drag in morphs

> 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

marcel.taeumel

Re: A suggestion: allowing ctrl+drag in morphs

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.

Re: A suggestion: allowing ctrl+drag in morphs

> First, let me acknowledge that this is kind of a regression. :-)
>
> Now, what is the situation here:
[...]

Ok, this is the master morphic architect view. It is valid, and I
consider you do a good job at this.

Now my view is from the morphic application developer side. I have a
morphic application requiring ctrl+drag, and I can make it work. It is
not even difficult. I just ask for a backdoor so that I don't have to
monkeypatch something as basic as the event handling mechanism.

The way I see it, you refuse by principle; and this amount to
deliberately enforcing a lack of functionality without any regard to the
actual need of actual morphic applications, of which I provided an
example. This I do not understand.

> 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".

I know. We already discussed this two years ago:
http://forum.world.st/cmdGesturesEnabled-false-gt-no-halos-td4882669.html

Nothing changed with regard to #cmdGesturesEnabled. I guess it is indeed
time for the split you propose.

> If you have more questions, keep on asking.

Please do not feel offended, but this remark is rather patronizing.

I am not asking anything, I am proposing something. As far as I am
concerned, things can stand as they are, I'll just keep hacking my way
into the current design.

I just thought I had something worthy to propose.

Best,

Stef

Nicolas Cellier

Re: A suggestion: allowing ctrl+drag in morphs

One question:
do we really depend on this VM hack for single button mouse, or can we nuke it and replace it by some image side preference?

2018-05-11 15:42 GMT+02:00 Stéphane Rollandin <[hidden email]>:

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

Now, what is the situation here:

[...]

Ok, this is the master morphic architect view. It is valid, and I consider you do a good job at this.

Now my view is from the morphic application developer side. I have a morphic application requiring ctrl+drag, and I can make it work. It is not even difficult. I just ask for a backdoor so that I don't have to monkeypatch something as basic as the event handling mechanism.

The way I see it, you refuse by principle; and this amount to deliberately enforcing a lack of functionality without any regard to the actual need of actual morphic applications, of which I provided an example. This I do not understand.

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".

I know. We already discussed this two years ago:
http://forum.world.st/cmdGesturesEnabled-false-gt-no-halos-td4882669.html

Nothing changed with regard to #cmdGesturesEnabled. I guess it is indeed time for the split you propose.

If you have more questions, keep on asking.

Please do not feel offended, but this remark is rather patronizing.

I am not asking anything, I am proposing something. As far as I am concerned, things can stand as they are, I'll just keep hacking my way into the current design.

I just thought I had something worthy to propose.

Best,

Stef

marcel.taeumel

Re: A suggestion: allowing ctrl+drag in morphs

In reply to this post by Stéphane Rollandin

Hi Stef,

well, since I tried to explain my thoughts and concerns, I suppose that I do not refuse just by principle. It seems that I have been failing to convey the bigger picture here. For that, I am sorry. I am no native English speaker; please treat any emotion I might transport with my words with care. I try to observe the situation, evaluate it in the context of my experiences, and make suggestions.

I will not add the backdoor you requested for the reasons I explained. I offered you some alternatives so that you can avoid "hacking [your] way into the current design." Sorry for any inconveniences. You brought up a very important topic, for which I am thankful.

Have a nice day!

Marcel

Am 11.05.2018 15:42:11 schrieb Stéphane Rollandin <[hidden email]>:
> First, let me acknowledge that this is kind of a regression. :-)
>
> Now, what is the situation here:
[...]

Ok, this is the master morphic architect view. It is valid, and I
consider you do a good job at this.

Now my view is from the morphic application developer side. I have a
morphic application requiring ctrl+drag, and I can make it work. It is
not even difficult. I just ask for a backdoor so that I don't have to
monkeypatch something as basic as the event handling mechanism.

The way I see it, you refuse by principle; and this amount to
deliberately enforcing a lack of functionality without any regard to the
actual need of actual morphic applications, of which I provided an
example. This I do not understand.

> 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".

I know. We already discussed this two years ago:
http://forum.world.st/cmdGesturesEnabled-false-gt-no-halos-td4882669.html

Nothing changed with regard to #cmdGesturesEnabled. I guess it is indeed
time for the split you propose.

> If you have more questions, keep on asking.

Please do not feel offended, but this remark is rather patronizing.

I am not asking anything, I am proposing something. As far as I am
concerned, things can stand as they are, I'll just keep hacking my way
into the current design.

I just thought I had something worthy to propose.

Best,

Stef

marcel.taeumel

Re: A suggestion: allowing ctrl+drag in morphs

Hi, everyone.

Please find attached a change set that splits up "cmdGesturesEnabled" into "metaMenuForAll" and "haloForAll". Note that even if disabled, any morph can decide to open the meta menu or the halo on its own. These preferences are rather development tools.

Best,

Marcel

Am 11.05.2018 16:02:37 schrieb Marcel Taeumel <[hidden email]>:
Hi Stef,

well, since I tried to explain my thoughts and concerns, I suppose that I do not refuse just by principle. It seems that I have been failing to convey the bigger picture here. For that, I am sorry. I am no native English speaker; please treat any emotion I might transport with my words with care. I try to observe the situation, evaluate it in the context of my experiences, and make suggestions.

I will not add the backdoor you requested for the reasons I explained. I offered you some alternatives so that you can avoid "hacking [your] way into the current design." Sorry for any inconveniences. You brought up a very important topic, for which I am thankful.

Have a nice day!
Marcel

Am 11.05.2018 15:42:11 schrieb Stéphane Rollandin <[hidden email]>:
> First, let me acknowledge that this is kind of a regression. :-)
>
> Now, what is the situation here:
[...]

Ok, this is the master morphic architect view. It is valid, and I
consider you do a good job at this.

Now my view is from the morphic application developer side. I have a
morphic application requiring ctrl+drag, and I can make it work. It is
not even difficult. I just ask for a backdoor so that I don't have to
monkeypatch something as basic as the event handling mechanism.

The way I see it, you refuse by principle; and this amount to
deliberately enforcing a lack of functionality without any regard to the
actual need of actual morphic applications, of which I provided an
example. This I do not understand.

> 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".

I know. We already discussed this two years ago:
http://forum.world.st/cmdGesturesEnabled-false-gt-no-halos-td4882669.html

Nothing changed with regard to #cmdGesturesEnabled. I guess it is indeed
time for the split you propose.

> If you have more questions, keep on asking.

Please do not feel offended, but this remark is rather patronizing.

I am not asking anything, I am proposing something. As far as I am
concerned, things can stand as they are, I'll just keep hacking my way
into the current design.

I just thought I had something worthy to propose.

Best,

Stef

halo-prefs.1.cs (6K) Download Attachment