[squeak-dev] Faster window drag for Morphic
Tim Johnson
digit at sonic.net
Sat Apr 2 17:11:50 UTC 2022
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
More information about the Squeak-dev
mailing list
|