[squeak-dev] Faster window drag for Morphic

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 5 17:12:51 UTC 2022


On Mon, Apr 4, 2022 at 12:18 AM Marcel Taeumel <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...
>

This is tangential, apologies, but I'm posting here to get visibility.  At
least in my updated trunk image, without "Fast window drag for
Morphic" enabled a dragged window disappears while it is being dragged.

>
> Best,
> Marcel
>
> Am 02.04.2022 19:32:41 schrieb tim Rowledge <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
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: DCVP: Destroy another Computer Via Phone-link
>
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220405/98097c05/attachment.html>


More information about the Squeak-dev mailing list