[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
|