[squeak-dev] Faster window drag for Morphic

Marcel Taeumel marcel.taeumel at hpi.de
Thu Jun 9 08:52:49 UTC 2022

Hi Karl --

If your changeset is the same as in Morphic-kfr.2002, this is not quite right. However, I hear your concerns that slower systems struggle with drag operations due to windows highlighting as a drop target even if not desired.

One simple fix for your personal image is to just hack #mouseEnterDragging:. But that's not for Trunk.

Also, please just be aware of that #performance flag I already documented there. So any correct improvement should be tested against that concern. It makes no sense to propose a proper fix without removing that flag comment. :-)

Am 06.06.2022 10:12:58 schrieb karl ramberg <karlramberg at gmail.com>:
Doh, error in previous change set. Hopefully fixed here

On Mon, Jun 6, 2022 at 10:02 AM karl ramberg <karlramberg at gmail.com [mailto:karlramberg at gmail.com]> wrote:

This change set  should  filter out unwanted drag and drop events for SystemWindows, so the window  doesn't activate on all kinds of mouse drags.

It needs some testing.


On Sun, Jun 5, 2022 at 11:54 PM Tim Johnson <digit at sonic.net [mailto:digit at sonic.net]> wrote:

Hi Karl,

Thanks for your insight here.  My original message in this thread was indeed re: SystemWindow>>mouseEnterDragging: and how commenting out "self activate." improves my experience — possibly at the expense of whatever facility this is supposed to support.  But without knowing which facility it is supposed to support, I couldn't test any changes I might make.  Now I can.  :) 

It's a rainy day and I'm stuck at home, so I went through them one by one and show my findings below.  This was to see if they (a) had an impact on the window becoming active, (b) were related to a feature I used, or (c) failed to respond as expected when "self activate" is commented out. (By "disabled by default", below, I mean the default set of preferences one gets from skipping the preference wizard at image startup.)

I might return to this by experimenting with your suggestion — "SystemWindows could here reject all other mouseOverDragging events than dragging TransferMorphs if the SystemWindows dropEnable is false."  Thanks.

tl;dr of below — (1) toggling the preferences did not impact the "windows become active" behavior — even if, perhaps, one of them /should/...?  while also, (2) the bottom two mechanisms do indeed require the window to be active for the submorphs to accept the drops (a valuable learning experience for me).

** 'System window embed ok' 
- disabled by default.  
- toggling this does not seem affect this behavior of "windows becoming active while other windows are dragged over them."  
- relates to feature I like and use:  dragging windows (inspectors, browsers, drawing morphs, whatever) over & "into" a project thumbnail on the world background.  I use this to separate my work out into different projects as my work diverges.  
- broken by commenting out "self activate"?  - no

** 'Browse with drag 'n' drop' 
- enabled by default.  
- toggling this does not seem affect this behavior of "windows becoming active while other windows are dragged over them."  
- relates to feature I like and use:  dragging a method list item from one (right-most) 'messageList' pane to another message category in the category list, to change its category.  Though I think this facility pre-dates the condition of windows becoming active for any morph being dragged over them(?).
- broken by commenting out "self activate"?  - yes

** 'Draggable Text Selections' 
- enabled by default.  
- toggling this does not seem affect this behavior of "windows becoming active while other windows are dragged over them."
- relates to feature I like and use:  I am not a user of this but it looks cool.
- broken by commenting out "self activate"?  - yes

The above would probably look better as a Swiki page;  I may do that but it's time to go do something else now.  :) 

Tim J

On Jun 5, 2022, at 8:10 AM, karl ramberg <karlramberg at gmail.com [mailto:karlramberg at gmail.com]> wrote:

There are different preferences acting here:

'System window embed ok' affects dropping windows on a PasteUpMorph or a ProjectViewMorph.
When preference is true, SystemWindows drops into the morph.

Sometimes useful, other times not what you want. This is probably not what you see in this case.

'Browse with drag 'n' drop' and 'Draggable Text Selections'

You can drag a text selection to another text pane or a list item to another list.
SystemWindows could here reject all other mouseOverDragging events than dragging TransferMorphs if the SystemWindows dropEnable is false.

See SystemWindow>>mouseEnterDragging:


On Sat, Jun 4, 2022 at 9:56 PM Tim Johnson <digit at sonic.net [mailto:digit at sonic.net]> wrote:

Hi Marcel, all,

Regarding the behavior of Browsers (etc.) becoming active when other tool-type windows are dragged over them and Fast Window Dragging is turned off:  why does this happen even when "drop in" (this used to be called "accept drops"*) is disabled?  

I recall the argument being made that the window can't know if any of its submorphs want the drop.  But doesn't the parent morph's "accept drops" setting take precedence over child morphs?  Or am I mistakenly applying non-Morphic logic to Morphic?  Not super clear from reading http://wiki.squeak.org/squeak/6194 [http://wiki.squeak.org/squeak/6194] .  (The practical implications of this are interesting to think about... and probably have been for years.  :) )

<Screen Shot 2022-06-04 at 11.43.35 AM.png>

There was a message posted to another thread on this list around the time I brought this up in which I detected (perhaps incorrectly) a sort-of "eye-rolling" tone (e.g. "ha ha, who would want to drop Workspaces into Browsers, amiright? ha ha [they don't know what they're missing!]").  This suggests to me that there must be other projects in Squeak which find it useful to have this behavior in the default configuration of the shipping image.  But what are those use cases?  Certainly it's not about "teleportation"-style morphs or any other custom windows which could have "accept drops" turned on and are not Browsers or Workspaces.  There must be some reason it's useful to have this behavior in the default shipping image even though (1) it slows down performance/introduces visible lag, (2) it seems (to me) to be a minority use case that e.g. a Workspace would be dropped onto a Browser, and (3) the morphs in question are not accepting drops...?

Tim J

* I don't want to get into the semantics wars, but in US English, "drop in" typically is used to describe an office or medical facility that does not require reservations, e.g. a "drop-in clinic."  I guess someone made the decision that "accept drops" was no longer acceptable...?  It is still referred to as such in various documentation:   http://wiki.squeak.org/squeak/6511 [http://wiki.squeak.org/squeak/6511https://wiki.squeak.org/squeak/6194 [https://wiki.squeak.org/squeak/6194] 

'Accept' is such common terminology w/r/t Morphs, it is a verb in the 'accept' / 'repel' protocol... 
https://github.com/hpi-swa-lab/SqueakByExample-english/blob/8287133e110d49c218e0a2ad6d6dc913adfe9b43/Morphic/Morphic.tex [https://github.com/hpi-swa-lab/SqueakByExample-english/blob/8287133e110d49c218e0a2ad6d6dc913adfe9b43/Morphic/Morphic.tex]

On Apr 4, 2022, at 12:18 AM, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:

Hi Tim --

Yes, thanks for the pointer. The question is whether we can know that not a single element in a window would like to accept the drop. I don't think we can. Windows can host all kinds of stuff, even other worlds (or instances of PasteUpMorph). Hmm... 

Am 02.04.2022 19:32:41 schrieb tim Rowledge <tim at rowledge.org [mailto:tim at rowledge.org]>:
It's a very long time since I played in this part of the sandpit but this seems like it might be amenable to the Morph>>#wantsDroppedMorph:event:/wantsToBeDroppedInto: protocol. And maybe the Morph>>#repelsMorph:event:/#rejectDropEvent: stuff too?

Surely the logic ought the include testing to see if the SystemWindow would ever be interested in accepting the drop?

> On 2022-04-02, at 10:11 AM, Tim Johnson wrote:
> Hi,
> I've been surprised about how SystemWindows become active when dragging other SystemWindows, Inspectors, PluggableXYZ windows (or morphs in general?) on top of (or over) them. It produces a noticable lag in the UI. This is only evident when the preference 'Fast window drag for Morphic' is turned OFF and whole windows are being dragged. (Having Soft shadows enabled slows it down further, I think.)
> IMHO these windows would not accept the drop, so they should not become active.
> I did some spying on the UI process and found that all code panes are being redrawn (?) when dragging morphs over SystemWindows. This is easily and quickly defeated/remedied by commenting out 'self activate' in the following method, as follows:
> SystemWindow>>#mouseEnterDragging: evt
> "unlock children for drop operations"
> self flag: #performance. "mt: There may be no need to change appearance if no widget wants the drop."
> self isActive ifTrue: [self lookFocused].
> (self isActive not and: [evt hand hasSubmorphs]) ifTrue: [
> "self activate." "unlock contents for drop"
> evt hand addMouseListener: self. "for drop completion on submorph"
> ].
> My question: could the drag-and-drop "#wantsXYZ" protocol be followed here to optimize this? Or perhaps there is some other way to /not/ make the window active (and thus redraw all its panes, I think?) when a morph /it does not want/ is dragged over it?
> Thanks
> Tim

tim Rowledge; tim at rowledge.org [mailto:tim at rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim]
Strange OpCodes: DCVP: Destroy another Computer Via Phone-link

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220609/98a804b2/attachment.html>

More information about the Squeak-dev mailing list