Sounds to me like the discussion has moved into the it-could-mean-just-about-anything stage. So far we have:

- sending morphs from one project to another
- perhaps selecting the destination based on some morph property
- perhaps the receiving project could refuse to accept the morph
- make the morph frontmost in the receiving project's world, unless that project doesn't even have a world

And other questions occur:

- why limit this to morphs? Why not send arbitrary data from project to project?
- is a morph a ui representation of some separate domain object? Where does the domain object live?
- what if the sending project is in "grid-view mode" and the receiving project is in "list-view mode"? Does sending a specific morph make any sense?
- why assume the morph would be installed in the world at the other end?
- do we assume the morph must be deleted from the sending world? Dropping a morph on a PVM will send a *copy* to the other project.

This all started with a simple problem that had a simple answer. Then many answers appeared without a clear notion of what the problem is. Who has a real problem that happens several times a day that takes too long to do? DTSTTCPW, anyone?

On 5/2/18 1:36 AM, H. Hirzel wrote:

On 5/2/18, Bob Arning <arning315@comcast.net> wrote:

a Flap would do that

Yes it does, but the new method discussed here will allow to send the
morph to another project without leaving the current project.

In addition, depending on how it is implemented,  a script might send
several morphs to different projects depending on their properties
(e.g. moving task cards around for a project mgmt system).

On 5/1/18 8:04 PM, Francisco Garau wrote:

I use to like the squeak trash bin morph were you could recover previously
deleted morphs.

How about a similar sort of morph that acts as a teleporter? You drop the
morphs in one project and recover it from any other.