[ENH] Drag/Drop: Morph>>aboutToDropInto:event:

David N. Smith (IBM) dnsmith at watson.ibm.com
Mon Jan 24 23:35:09 UTC 2000


Bob:

Thanks for the long informative note. I'll try to present an alternative view that makes sense.

At 20:08 -0500 1/23/2000, Bob Arning wrote:
>On Sun, 23 Jan 2000 19:08:54 -0500 "David N. Smith \(IBM\)" <dnsmith at watson.ibm.com> wrote:
>>I've been doing lots of dragging and dropping and I could not find a message that got sent to the morph that is about to be dropped into a target morph. There is one that happens just *after* the drop, but the dropped morph has already been accepted and side effects may have already happened.
>
>Hi Dave,
>
>This is an interesting problem and finding the right balance has some subtleties. One of those is the degree of negotiation between the dropped morph and the new (potential) owner. One can certainly envision an application where morphs of TypeA are only intended to be dropped into morphs of TypeB, excluding all other types of morphs typically present in the application as possible recipients. But what happens with the introduction of parts bin or parking area morphs? Can they override the dropped morph's preference and force the drop to happen?

Maybe a bit of background is suitable here. I've got two test cases:

1) A HangMan game where the dragged letter morph is dropped on a phrase morph which extracts the associated letter, greys out the dropped morph, and puts it back where it was; it cannot be dragged again. If an unused letter morph is dropped elsewhere it just puts itself back (but see below).

2) In a different letter game the letter morph is dropped on a word morph in an attempt to guess a word; the letters can be reused. When dropped on the word morph, the letter morph is copied and the original is placed back where it was. The copy is placed in the word morph for display. If the dragged letter is dropped elsewhere it just puts itself back. Only letters that can be next in a word in the dictionary are suitable for dropping.

Neither kind of letter morph is suitable for a toolbox. In fact, they must only be used in context. (The morphs which hold the letters may be useful in a toolbox though).

>FWIW, I've handled this in a couple of ways in the past:
>
>1. It is still possible to alter the situation radically in #justDroppedInto:event: on the dropped morph. The dropped morph can delete itself and
>1a. Put itself somewhere else.
>1b. Put something else in its place
>1c. Disappear entirely.
>
>2. Have a negotiation in #dropTargetFor:event: or #wantsDroppedMorph:event: on the potential recipient that allows the recipient to query the dropping morph as to suitability. A parts-bin-like morph might accept any morph while other recipients might require certain attributes, e.g. an AppointmentBook might accept anything whose protocol supports #date, #time and #description.

Actually, HangMan does what you suggest in #1. It works except when the accepting morph does something to the morph immediately, like the trash can throwing the morph away, or a color changer morph which changes the color of a morph depending on the color of the place the morph is dropped, or a motion playing field morph which causes the dropped morph to move around? One never knows what an accepting morph might do before one has a chance to get the dropped morph back out; one has to be prepared to completely rebuild the dropped morph from scratch in order to make sure its state is the same.

I've tried the trash can and color changing examples. There is no way to avoid the color change (without my enhancement), and the trash can throws the morph away (with preferences set right), producing a walkback when the morph is put back.

>I have the feeling that the current architecture is mostly construction-oriented while the extensions we need are more application-oriented.

I agree, and the extension I suggested helps an application maintain control, and plugs a logical hole in drag/drop.

>BTW, whatever course you choose, I'd seek to minimize the side-effects of a morph being accepted on the drop. What matters in the long run is whether the morph actually stays. The sequence:
>
>Hand: do you want this?
>Recipient: OK.
>Hand: Fine, here it is.
>Dropped: Not so fast! I'd rather be over there.
>
>isn't really anything more than
>
>recipient add: this.
>recipient remove: this.
>
>And I'd think you would want that that sequence to be handled successfully, whatever the point of origin.

The proposed extension doesn't change any existing negotiation, nor does it add significantly to the overhead. A single message is sent to the about-to-be dropped morph and the default is to answer true. As I said above, the sequence you give is, IMHO, flawed since there is no way for the application to know what was done when the dropped morph was accepted.

I don't think that dropped morphs should be second class citizens, subject to the whims of whichever 'slaveholder' morph happens to get hold of them for a moment.

I just temporarily removed use of the enhancement and found that things don't work when the dragged letter morph is dropped on the trash can. The trash can immediately deletes the morph, leaving it hanging in outer space. Then #slideBackToFormerSituation: dies because it assumes that the morph lives in a world and it can query the viewBox of that world. This is a good example of why one doesn't want to just drop a morph on any arbitrary other morph. I need to kid-proof things so that even a malicious little, uh, student can't screw things up too badly for a teacher to fix.

There are other trash can problems with my enhancement installed: not closing the lid, and causing the hand to hide what it is carrying when it is over the trash. If I drop the morph and my enhancement is being used, it's immediately whisked away by #slideBackToFormerSituation: and is never dropped on the trash can. Moving the hand away from the trash can does not cause the hand to set itself back to showing things that are held, nor does it close the lid. I think it's a bug in the trash can that this code just uncovered. (And I guess I need to fix it!)

Again, thanks for the discussion.

Dave


Here is a morph that changes the color of any other morph dropped on it. It's a prime example of the kind of thing you *don't* want to drop your morph on unintentionally and then try to get it back.

'From Squeak2.7 of 5 January 2000 [latest update: #1789] on 24 January 2000 at 6:25:02 pm'!
RectangleMorph subclass: #JunkColorChangerMorph
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Junk-Junky'!

!JunkColorChangerMorph methodsFor: 'as yet unclassified' stamp: 'dns 1/24/2000 17:11'!
acceptDroppingMorph: aMorph event: anEvent
	aMorph color: self color! !

!JunkColorChangerMorph methodsFor: 'as yet unclassified' stamp: 'dns 1/24/2000 17:12'!
initialize
	super initialize.
	self openDragAndDrop.! !

_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.





More information about the Squeak-dev mailing list