[squeak-dev] About the transferMorphConverter logic

Chris Muller asqueaker at gmail.com
Mon Apr 19 23:33:50 UTC 2010

Hi Stef,

> - When the transferMorphConverter is not #yourself, any TransferMorph is
> supposed to translate into a suitable Morph to drop. This may not always be
> the case though; in muO, some TransferMorphs are suitable, some not.
> Currently there is no way to handle unsuitable ones (I have made a
> VanishingMorph which is deleted as soon as it gets a new owner to handle the
> case)

Yep, I didn't see an easy way to do this either..  I think what you
did is good because, if a TransferMorph drop doesn't complete, then
the image becomes virtually unusable in that, for left-clicks to
register, you have to move the mouse simultaneously with the click for
it to be detected.

Morph>>#handleDropMorph: is the mainline logic for DnD.  If a morph is
not suitable, then it should answer false to #wantsToBeDroppedInto:.
But yes, so the logic associated with TransferMorph is "generic", and
so is based merely the presence of a transferMorphSelector.

> - There does not seem to be a way to give a default transferMorphConverter
> for new morphic projects.

That does seem like it would be a good idea..  Can you intercept the
event of a project switch and set it then?

> I guess this should happen in
> PasteUpMorph>>beWorldForProject:, with some registering mechanism for
> defining the default value.

I implemented the minimum to be able to intercept the event.  I can
still use some improvement!

 - Chris

More information about the Squeak-dev mailing list