On Tue, Apr 5, 2022 at 11:35 PM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Eliot --
>
> > At least in my updated trunk image, without "Fast window drag for
> Morphic" enabled a dragged window disappears while it is being dragged.
>
> Either update your Trunk image or do-it: "WorldState
> disableDeferredUpdates: true. Project current world canvas: nil". The macOS
> backends did not have a VM-side composition buffer for a long time. With
> the current OSVM, you just have to turn on that image-side composition
> buffer, which has been around since 1999.
>

I do apologize.  I thought I'd updated.  Thanks, and sorry for the noise.

>
> Best,
> Marcel
>
> Am 05.04.2022 19:13:18 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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
>
>
>

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