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

On Nov 1, 2018, at 7:49 AM, commits@source.squeak.org wrote:

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!