Hi Karl --

I do not agree with this fix here. For example, the System Browser window answers "false" for #dropEnabled but some of its lists do accept drops.

-1

It seems to be a matter of granularity. Hmm... we would need a quick check for "does any of my sub(sub)morphs accept that drop?" Just asking the window itself is not enough. Regular event handling primarily works bottom to top, not the other way around.

Best,
Marcel
Am 06.06.2022 11:36:18 schrieb commits at source.squeak.org <commits at source.squeak.org>:
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-kfr.2002.mcz

==================== Summary ====================

Name: Morphic-kfr.2002
Author: kfr
Time: 6 June 2022, 11:35:56.143783 am
UUID: 3700dde9-4ef0-c84e-a342-23f649a554e3
Ancestors: Morphic-kfr.2001

Don't activate SystemWindows on drags events it doesn't want

=============== Diff against Morphic-kfr.2001 ===============

Item was changed:
----- Method: SystemWindow>>mouseEnterDragging: (in category 'events') -----
mouseEnterDragging: evt
"unlock children for drop operations"

+ | textDnD |
self flag: #performance. "mt: There may be no need to change appearance if no widget wants the drop."
+
+ textDnD := false.
+ evt hand hasSubmorphs ifTrue:[textDnD := evt hand firstSubmorph isTransferMorph]. "Workaround: We sometimes get this event triggered when there is no submorph to the hand"
+ (textDnD or:[self dropEnabled]) ifFalse: ["if both are false there is no d&d"
+ ^super mouseEnterDragging: evt].
+
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"
].!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220609/966c8759/attachment.html>