Thanks Marcel and Tim.

Do ToolBuilder / SystemWindow / PluggableXYZ / Browser morphs typically 
contain PasteUpMorphs and other worlds, though?  I haven't seen that in my 
own explorations.  Maybe with Connectors installed, and other packages 
that use custom "code holder" views...?

Is it possible for a SystemWindow / Browser to just ask its own child 
morphs / embedded panes under the Hand if they want the drop?

I see the comments in the method about 'unlocking' the window... is 
'unlocking' necessary to query child morphs?  I wonder if the Morphic 
menu option of 'allow embedding' (sorry, don't have it in front of me 
right now) could come into play here, possibly.

I realize that dragging certain morphs onto Browsers is a standard use 
case:  I like using the feature of dragging-and-dropping a CompiledMethod 
morph from one Browser to another, for example.  But dragging Inspectors 
and Browsers over other Inspectors and Browsers should not trigger an 
entire refresh of those windows unless truly necessary, IMHO.

Speaking of other worlds:  I remember when collapsed Project morphs were 
fixed to once again allow dropping windows & morphs into them, to 
'transport' that morph into other Projects.  I think this might have been 
part of that fix.  I still really enjoy that feature.

Tim

On Mon, 4 Apr 2022, Marcel Taeumel 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... 
> 
> 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
> 
> 
> 
> 
>