[squeak-dev] Morphic window dragging broken (was: Faster window drag for Morphic)

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 5 21:49:33 UTC 2022


On Tue, Apr 5, 2022 at 12:14 PM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> > At least in my updated trunk image, without "Fast window drag for
> Morphic" enabled a dragged window disappears while it is being dragged.
>
>
> Hi Eliot,
>
>
> thank you for letting us know. Could you maybe share a
> screencast/screenshot of the issue? Does the window disappear entirely or
> just a part of it? Does the issue occur as well when you resize it or use
> the halo to move/grab/resize it? Does the issue also occur for dialog
> windows (for instance, from the "find class" dialog)?
>

Any window disappears entirely once the mouse is moved while pressing the
red button with the cursor within the window's title bar.  The window
appears cirrectly in the new position once the mouse button is released.
There is no point showing a screen shot because there is no window to see.
This does indeed also affect dialog and menu windows.

> I have ensured recently that drop shadows will be hidden during window
> dragging. But it is unexplainable to me how the rest of the windows could
> appear, too.
>
>
> Best,
>
> Christoph
>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
> *Gesendet:* Dienstag, 5. April 2022 19:12 Uhr
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] Faster window drag for Morphic
>
>
>
> 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/20220405/dd92ea44/attachment-0001.html>


More information about the Squeak-dev mailing list