The Trunk: 53Deprecated-pre.2.mcz

Patrick Rein uploaded a new version of 53Deprecated to project The Trunk:
http://source.squeak.org/trunk/53Deprecated-pre.2.mcz

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

Name: 53Deprecated-pre.2
Author: pre
Time: 1 November 2018, 3:49:25.914943 pm
UUID: 67b0129c-faea-074b-9be1-bea4e0e444c2
Ancestors: 53Deprecated-pre.1

Deprecates two drag and drop menu methods. One broke with the naming convention for menu item selectors and the other is unnecessary as the superclass already implements the same behavior.

=============== Diff against 53Deprecated-pre.1 ===============

Item was added:
+ ----- Method: Morph>>toggleDragNDrop (in category '*53Deprecated-dropping/grabbing') -----
+ toggleDragNDrop
+ "Toggle this morph's ability to add and remove morphs via drag-n-drop."
+
+ self enableDragNDrop: self dragNDropEnabled not.
+ !

Item was added:
+ ----- Method: PasteUpMorph>>isOpenForDragNDropString (in category '*53Deprecated-menu & halo') -----
+ isOpenForDragNDropString
+ "Answer the string to be shown in a menu to represent the  
+ open-to-drag-n-drop status"
+ ^ (self dragNDropEnabled
+ ifTrue: ['<on>']
+ ifFalse: ['<off>'])
+ , 'open to drag & drop' translated!

Hi everyone,

just realized the plan was to go to 60Deprecated directly. I will change this immediately. Disregard these commits :)

Bests
Patrick

________________________________________
From: Squeak-dev <[hidden email]> on behalf of [hidden email] <[hidden email]>
Sent: Thursday, November 1, 2018 15:49
To: [hidden email]; [hidden email]
Subject: [squeak-dev] The Trunk: 53Deprecated-pre.2.mcz

Patrick Rein uploaded a new version of 53Deprecated to project The Trunk:
http://source.squeak.org/trunk/53Deprecated-pre.2.mcz

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

Name: 53Deprecated-pre.2
Author: pre
Time: 1 November 2018, 3:49:25.914943 pm
UUID: 67b0129c-faea-074b-9be1-bea4e0e444c2
Ancestors: 53Deprecated-pre.1

Deprecates two drag and drop menu methods. One broke with the naming convention for menu item selectors and the other is unnecessary as the superclass already implements the same behavior.

=============== Diff against 53Deprecated-pre.1 ===============

Item was added:
+ ----- Method: Morph>>toggleDragNDrop (in category '*53Deprecated-dropping/grabbing') -----
+ toggleDragNDrop
+       "Toggle this morph's ability to add and remove morphs via drag-n-drop."
+
+       self enableDragNDrop: self dragNDropEnabled not.
+ !

Item was added:
+ ----- Method: PasteUpMorph>>isOpenForDragNDropString (in category '*53Deprecated-menu & halo') -----
+ isOpenForDragNDropString
+       "Answer the string to be shown in a menu to represent the
+       open-to-drag-n-drop status"
+       ^ (self dragNDropEnabled
+               ifTrue: ['<on>']
+               ifFalse: ['<off>'])
+               , 'open to drag & drop' translated!

Hi Patrick,

I am excited to try these out.  Thanks.

This also inspired me to ask if you might have any insight into the following behavior, which has existed since before the release of 5.2, but perhaps not for all of history:  dragging windows (say, a Browser, for example) around a Morphic project causes underlying windows (windows behind the window you are dragging) to 'activate' as the mouse moves over them, as if they are indicating they can accept a dropped morph.  This seems to be the case whether "focus follows mouse" is turned on or off (I usually have 'on', but just tested with it 'off').  It is also the case when the 'underlying' morph has "accept drops" turned off.

Just curious if this is errant behavior or serves some useful purpose :)

Best,
Tim J