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 <lecteur at zogotounga.net>:
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

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