About the transferMorphConverter logic

In my current effort of porting muO to 4.1 I stumbled upon the new logic
to handle the way TransferMorphs are dropped into the World.

The idea is nice, but the implementation is lacking IMHO. Here are some
troublesome points:

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

- There does not seem to be a way to give a default
transferMorphConverter for new morphic projects. I guess this should
happen in PasteUpMorph>>beWorldForProject:, with some registering
mechanism for defining the default value.


Stef

Stéphane Rollandin wrote:
This is the kind of thing that OpenDoc addressed. You might want to
check and see how OD handled it.


Lawson

> This is the kind of thing that OpenDoc addressed. You might want to
> check and see how OD handled it.

Thanks, although I have no idea about what OpenDoc is. Google did not
help much; any pointer ?

Stef

On 19.04.2010, at 10:03, Stéphane Rollandin wrote:
>
>> This is the kind of thing that OpenDoc addressed. You might want to
>> check and see how OD handled it.
>
> Thanks, although I have no idea about what OpenDoc is. Google did not help much; any pointer ?
>
> Stef

http://en.wikipedia.org/wiki/OpenDocument

Q: What do you get if you mix the Open Document Format, Tweak, Etoys, and TeaTime?
A: TinLizzie WysiWiki

That's one of the research prototypes done at Viewpoints in 2007. You could e.g. use Open Office to open an Etoys project, edit, save, and run the changed version in Squeak again. The Open Document Format is extensible, and Open Office preserves unknown tags, so the Etoys scripts were unharmed, even though Open Office could not interpret them:

http://www.vpri.org/pdf/tr2007001_tinlizz.pdf

- Bert -

ok, thanks

I don't think this really relates to my original post though..

best,

Stef

On 19.04.2010, at 11:53, Stéphane Rollandin wrote:
>
> ok, thanks
>
> I don't think this really relates to my original post though..
>
> best,
>
> Stef

Hehe. I didn't even read the original question ;) I may very will be way off and Lawson meant something entirely different.

Sometimes, snipping too much of a conversation makes it hard to follow (like this message of yours). Trimming - good. No context - bad. :)

- Bert -

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