Changes to mouseUp handling?

Raab, Andreas Andreas.Raab at disney.com
Tue Nov 7 19:44:41 UTC 2000


Ned,

> Yes. Right now the Hand asks the World what to do in the case where
> the drag'n'drop doesn't get accepted.

Well, that's not quite true. If you look at the code in question (e.g.,
HandMorph>>dropMorph:event:) you will find that the morph that was being
dropped is asked what to do about an unsuccessful drop operation (e.g.,
#rejectDropMorphEvent: is called). The world acts only as the root for
dispatching incoming events from the hand.

BTW, the above (e.g., #rejectDropMorphEvent:) does actually allow you to
take control directly (though it's a bit of a hack). Since all drops have
symmetric checks, you can implement #wantsToBeDroppedInto: by returning
false and then implement #rejectDropMorphEvent: to do whatever seems useful.

> The limitation of that is that it
> makes it hard to make an editor that works in a window (haven't looked
> at the world-in-world stuff yet, though).

I don't quite understand - as I said above, the world is nothing but the
root for the drop event (it has to start somewhere with the dispatch, has
it?!). Also, by implementing #wantsToBeDroppedInto: you could actually check
if the drop receiver is a child of the "window" you want to be dropped into.

> > So what to do.  We could extend morphic so that when a 
> > morph is about to be dropped, then the dropped morph is
> > first asked if it wants control over the drop.  Most morphs will say
> > no, but Ned's would say yes. Only if morphs say no, would
> > a hand morph look around for a morph to accept the drop and
> > take control.  It's yet one more addition to the protocols,
> > but drag and drop just plain seems to be complicated.

I'm not quite sure if I like it. E.g., now we have that one special Morph
that wants to take control - what happens if we have another morph that
wants to take control even if the morph carried around is one of those
"control-takers"?! As I said above, it's utterly trivial to get rid of the
entire drop behavior by implementing two methods (one returning false and
the other one doing the control thing) so that - at least for now - I don't
see a big reason to introduce a new protocol here.

  - Andreas





More information about the Squeak-dev mailing list