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

Bob Arning arning at charm.net
Mon Jan 24 01:08:01 UTC 2000


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?

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.

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

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.

Cheers,
Bob





More information about the Squeak-dev mailing list