Morph dropping (was: RE: [BUG][FIX][TEST] Morph adding/removing ( introduces drop reject bug ))

Andreas Raab andreas.raab at gmx.de
Tue Aug 12 18:19:29 UTC 2003


> With the MorphRemoval-ar.3.cs changeset loaded in a clean 5395 image.
> 
> Open an Objects tool.
> Drop a Star on it.
> Get a walkback.

Good catch. HandMorph>>dropMorph:event: was one of the few places which used
#privateRemoveMorph: without setting the owner to nil afterwards. While the
symptom would be trivial to fix (just use "anEvent hand world" in
#slideBackToFormerSituation:) there is a good question about whether the
morph should be really "out of the world" during the drop.

I'm not certain about this ... not at all. On one hand it seems as if things
should continue to work if we just fix the above problem but conceptually,
it sounds very, very wrong. While the morph is "falling down" it should most
certainly be in the world (where would it fall if it weren't???) and it
would (quite implicitly) end up in the right place (the world) if noone
handles that drop. On the other hand, I have no idea what other implicit
assumptions about dropping is in the code now, so I simply don't know if
anything is going to break.

Any ideas?

Cheers,
  - Andreas



More information about the Squeak-dev mailing list