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 at 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.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180502/a3adb903/attachment.html>