Doh, error in previous change set. Hopefully fixed here

On Mon, Jun 6, 2022 at 10:02 AM karl ramberg <karlramberg at gmail.com> wrote:

> This change set  should  filter out unwanted drag and drop events for
> SystemWindows, so the window  doesn't activate on all kinds of mouse drags.
>
> It needs some testing.
>
> Best,
> Karl
>
> On Sun, Jun 5, 2022 at 11:54 PM Tim Johnson <digit at sonic.net> wrote:
>
>> Hi Karl,
>>
>> Thanks for your insight here.  My original message in this thread was
>> indeed re: SystemWindow>>mouseEnterDragging: and how commenting out "self
>> activate." improves my experience — possibly at the expense of whatever
>> facility this is supposed to support.  But without knowing which facility
>> it is supposed to support, I couldn't test any changes I might make.  Now I
>> can.  :)
>>
>> It's a rainy day and I'm stuck at home, so I went through them one by one
>> and show my findings below.  This was to see if they (a) had an impact on
>> the window becoming active, (b) were related to a feature I used, or (c)
>> failed to respond as expected when "self activate" is commented out. (By
>> "disabled by default", below, I mean the default set of preferences one
>> gets from skipping the preference wizard at image startup.)
>>
>> I might return to this by experimenting with your suggestion —
>> "SystemWindows could here reject all other mouseOverDragging events than
>> dragging TransferMorphs if the SystemWindows dropEnable is false."  Thanks.
>>
>> tl;dr of below — (1) toggling the preferences did not impact the "windows
>> become active" behavior — even if, perhaps, one of them /should/...?  while
>> also, (2) the bottom two mechanisms do indeed require the window to be
>> active for the submorphs to accept the drops (a valuable learning
>> experience for me).
>>
>> ** '*System window embed ok*'
>> - disabled by default.
>> - toggling this does not seem affect this behavior of "windows becoming
>> active while other windows are dragged over them."
>> - relates to feature I like and use:  dragging windows (inspectors,
>> browsers, drawing morphs, whatever) over & "into" a project thumbnail on
>> the world background.  I use this to separate my work out into different
>> projects as my work diverges.
>> - broken by commenting out "self activate"?  - no
>>
>> ** '*Browse with drag 'n' drop'*
>> - enabled by default.
>> - toggling this does not seem affect this behavior of "windows becoming
>> active while other windows are dragged over them."
>> - relates to feature I like and use:  dragging a method list item from
>> one (right-most) 'messageList' pane to another message category in the
>> category list, to change its category.  Though I think this facility
>> pre-dates the condition of windows becoming active for any morph being
>> dragged over them(?).
>> - broken by commenting out "self activate"?  - yes
>>
>> ** '*Draggable Text Selections*'
>> - enabled by default.
>> - toggling this does not seem affect this behavior of "windows becoming
>> active while other windows are dragged over them."
>> - relates to feature I like and use:  I am not a user of this but it
>> looks cool.
>> - broken by commenting out "self activate"?  - yes
>>
>>
>> The above would probably look better as a Swiki page;  I may do that but
>> it's time to go do something else now.  :)
>>
>> Best,
>> Tim J
>>
>>
>> On Jun 5, 2022, at 8:10 AM, karl ramberg <karlramberg at gmail.com> wrote:
>>
>> There are different preferences acting here:
>>
>> 'System window embed ok' affects dropping windows on a PasteUpMorph or a
>> ProjectViewMorph.
>> When preference is true, SystemWindows drops into the morph.
>> Sometimes useful, other times not what you want. This is probably not
>> what you see in this case.
>>
>> 'Browse with drag 'n' drop' and 'Draggable Text Selections'
>> You can drag a text selection to another text pane or a list item to
>> another list.
>> SystemWindows could here reject all other mouseOverDragging events than
>> dragging TransferMorphs if the SystemWindows dropEnable is false.
>> See SystemWindow>>mouseEnterDragging:
>>
>> Best,
>> Karl
>>
>>
>> On Sat, Jun 4, 2022 at 9:56 PM Tim Johnson <digit at sonic.net> wrote:
>>
>>> Hi Marcel, all,
>>>
>>> Regarding the behavior of Browsers (etc.) becoming active when other
>>> tool-type windows are dragged over them and Fast Window Dragging is turned
>>> off:  why does this happen even when "drop in" (this used to be called
>>> "accept drops"*) is disabled?
>>>
>>> I recall the argument being made that the window can't know if any of
>>> its submorphs want the drop.  But doesn't the parent morph's "accept drops"
>>> setting take precedence over child morphs?  Or am I mistakenly applying
>>> non-Morphic logic to Morphic?  Not super clear from reading
>>> http://wiki.squeak.org/squeak/6194 .  (The practical implications of
>>> this are interesting to think about... and probably have been for years.
>>>  :) )
>>>
>>> <Screen Shot 2022-06-04 at 11.43.35 AM.png>
>>>
>>> There was a message posted to another thread on this list around the
>>> time I brought this up in which I detected (perhaps incorrectly) a sort-of
>>> "eye-rolling" tone (e.g. "ha ha, who would want to drop Workspaces into
>>> Browsers, amiright? ha ha [they don't know what they're missing!]").  This
>>> suggests to me that there must be other projects in Squeak which find it
>>> useful to have this behavior in the default configuration of the shipping
>>> image.  But what are those use cases?  Certainly it's not about
>>> "teleportation"-style morphs or any other custom windows which could have
>>> "accept drops" turned on and are not Browsers or Workspaces.  There must be
>>> some reason it's useful to have this behavior in the default shipping image
>>> even though (1) it slows down performance/introduces visible lag, (2) it
>>> seems (to me) to be a minority use case that e.g. a Workspace would be
>>> dropped onto a Browser, and (3) the morphs in question are not accepting
>>> drops...?
>>>
>>> Thanks,
>>> Tim J
>>>
>>> * I don't want to get into the semantics wars, but in US English, "drop
>>> in" typically is used to describe an office or medical facility that does
>>> not require reservations, e.g. a "drop-in clinic."  I guess someone made
>>> the decision that "accept drops" was no longer acceptable...?  It is still
>>> referred to as such in various documentation:
>>> http://wiki.squeak.org/squeak/6511 https://wiki.squeak.org/squeak/6194
>>>
>>> 'Accept' is such common terminology w/r/t Morphs, it is a verb in the
>>> 'accept' / 'repel' protocol...
>>>
>>> https://github.com/hpi-swa-lab/SqueakByExample-english/blob/8287133e110d49c218e0a2ad6d6dc913adfe9b43/Morphic/Morphic.tex
>>>
>>>
>>>
>>> On 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...
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220606/793432e8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SystemWindow.kfr.3.cs
Type: application/octet-stream
Size: 787 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220606/793432e8/attachment-0001.obj>