How do I move a morph from one project to another?

- drop it into a shared flap and take it out on the other project

- open an explorer on the morph and then "(Project named: 'whatever') world addMorph: self"

Hi.

I had a progress morph that opened up in one project, and then was stuck (background progress had an issue).  I left the progress up and ignored the bug for a bit - I needed to switch to a different project for other work.

That other work also opened the system progress morph, and naturally moved the single system progress morph to this other project.

I now won't to go back to the original project and work through the bug.  Of course, the progress is in the wrong project now - I'd like it back in the project that it is showing the progess for.

Is there a magic menu item somewhere that I can send a morph to a specific project?  It is a sibling project - the project the morph is in and the project I want to move the morph to are both children of the same 'parent' project.

(Of course, I can just cause the progress morph to move by showing more progress - but I'd like to know in general.  I can move morphs down into projects - just drag and drop.  Not sure how to move them up or over.)

-cbc

Hi Chris,

On 04/30/2018 05:44 PM, Chris Cunningham wrote:
> Is there a magic menu item somewhere that I can send a morph to a
> specific project?

I solved part of this in 2005, for SystemWindows only, though I'm sure
it would generalize to other morphs straightforwardly:

 - blog post:
http://www.lshift.net/blog/2005/08/19/how-hard-can-it-possibly-be/
    (mirror:)
http://homepages.kcbbs.gen.nz/tonyg/lshift_archive/how-hard-can-it-possibly-be-20050819.html

 - squeak-dev posting with changeset:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/093538.html

Cheers,
  Tony

That's a combination of odd factors.

- MenuMorph implements #morphicLayerNumber

- MenuMorph is generally added to the world with something like "aWorld addMorphFront: self."

- PasteUpMorph>>addMorphFront: ignores the method #morphicLayerNumber, but does check the property by the same name (and if missing assumes 100)

- so the menu ends up behind the progress morph which does have a layer of 12

This could be fixed by either

    self setProperty: #morphicLayerNumber toValue: self morphicLayerNumber.
    aWorld addMorphFront: self; startSteppingSubmorphsOf: self.

or

    aWorld addMorphInLayer: self; startSteppingSubmorphsOf: self.

in the MenuMorph pop up method(s)

While doing this, bringing up the debug menu brought the menu up UNDER the progress morph (visually), but the debug morph was still active even though it is under the progress morph.  Very weird.

> Is there a magic menu item somewhere that I can send a morph to a
> specific project?

I have that in my muO images (such as the available at
http://www.zogotounga.net/comp/squeak/muo/muO335.zip), it is an item
from the red halo handle, "send to project..."

The implementation is


Morph>>sendToAnotherProject

        | target |
       
        target := Project queryProject ifNil: [^ self].
        target world addMorph: self



Project class>>queryProject

        | selection nBack prev |
       
        selection := (Project buildJumpToMenu: CustomMenu new) startUpLeftFlush.

        selection ifNil: [^ nil].
        (selection beginsWith: '%back') ifTrue:
                [nBack := (selection copyFrom: 6 to: selection size) asNumber.
                prev := CurrentProject previousProject.
                1 to: nBack-1 do:
                        [:i | prev ifNotNil: [prev := prev previousProject]].
                prev ifNotNil: [^ prev]].
        selection = #parent ifTrue:
                [^ CurrentProject parent].
        ^ Project namedWithDepth: selection.



Project class>>buildJumpToMenu: menu

        | listed i  toAdd |
        listed := OrderedCollection with: CurrentProject.
        i := 0.

        CurrentProject isTopProject ifFalse:
                [self addItem: CurrentProject parent name , ' (parent)'
                                toMenu: menu
                                selection: #parent
                                project: CurrentProject parent.
                  menu addLine].

        (Preferences alphabeticalProjectMenu
                        ifTrue:
                                [Project allNamesAndProjects]
                        ifFalse:
                                [Project hierarchyOfNamesAndProjects]) do:

                [:aPair |
                        toAdd := aPair last isCurrentProject
                                ifTrue:
                                  [aPair first, ' (current)']
                                ifFalse:
                                  [aPair first].
                        self addItem: toAdd
                                toMenu: menu
                                selection: aPair first
                                project: aPair last].
        ^ menu



Stef

There is more than one way to add a morph to a world: front, back, in layer, before, after, etc. Might be a lot of extra methods that would rarely be used.

I'm talking my way into adding something like this to Trunk.  But, shouldn't we just addMorph: to project, instead of looking at its world to add it there?  Yes, it doesn't support this yet, but shouldn't it with appropriate encapsulation?

On 5/1/18, Bob Arning <[hidden email]> wrote:
> There is more than one way to add a morph to a world: front, back, in
> layer, before, after, etc. Might be a lot of extra methods that would
> rarely be used.

So it is necessary to go for some useful default values only ....

It makes sense that the morph in the receiving project will be the
topmost morph.

>
> On 5/1/18 11:54 AM, Chris Cunningham wrote:
>> I'm talking my way into adding something like this to Trunk. But,
>> shouldn't we just addMorph: to project, instead of looking at its
>> world to add it there?  Yes, it doesn't support this yet, but
>> shouldn't it with appropriate encapsulation?
>>
>
>

> On 01-05-2018, at 9:51 AM, Bob Arning <[hidden email]> wrote:
>
> There is more than one way to add a morph to a world: front, back, in layer, before, after, etc. Might be a lot of extra methods that would rarely be used.
>
> On 5/1/18 11:54 AM, Chris Cunningham wrote:
>> I'm talking my way into adding something like this to Trunk.  But, shouldn't we just addMorph: to project, instead of looking at its world to add it there?  Yes, it doesn't support this yet, but shouldn't it with appropriate encapsulation?
>>
>

But for the common case of wanting to teleport a Morph from one project to another we can make a nice clean abstraction. Like maybe
     Project chooseNewProjectAndMoveMorph: self
This makes it convenient for Project to use the appropriate UI as for opening browsers etc and hides possible different arrangements for the way morphs might live in the new project. After all, a new kind of project might now have a world concept; we shouldn't know or care at this point.
Perhaps return the destination Project or nil so we can do something further if the user chose to cancel or the project declined to accept the transfer. Again, send something like #acceptTransferOfMorph: theMorph to the chosen Project.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: NNI: Neglect Next Instruction

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.

It should have the Tardis icon ;-)

- Francisco

a Flap would do that

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. 

On 5/2/18, Bob Arning <[hidden email]> 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.
>
>

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, Bob Arning [hidden email] 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.

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

I use projects mostly as virtual desktops where I keep different aspects
of my work (be it development or music composition) more or less cleanly
separated.

When I realize that what I'm working on is not anymore in the meant
scope of the current project, I create a new project and dispatch all
workspaces, browsers and other tools (including homemade ones such as
musical editors) that live in the current (usually crowded) World to the
world of that project.

So I only deal with top-level morphs, and as I said earlier I added an
item in their red handle menu to easily send them away (usually several
morphs in a row). I also have another item for sending a morph copy to
another project, but I use this one much less often.


Stef

Bob, thank you for the good summary of the points of discussion.
I work in a similar way as Stéphane describes.

--Hannes

On 5/2/18, Stéphane Rollandin <[hidden email]> wrote:

You must raise halo, made a tile of morph and put this tile in the target project.
Switch project and click on tile .


Edgar
@morplenauta




On 30/04/2018, 13:44, "Chris Cunningham" <[hidden email]> wrote:

Is there a magic menu item somewhere that I can send a morph to a specific project?  It is a sibling project - the project the morph is in and the project I want to move the morph to are both children of the same 'parent' project.

In the course of this discussion, it seemed like drag&drop might be handy for some use cases. Attached is a (really simple) DropZoneMorph that can do whatever you like to things dropped into it.

Bob, thank you for the good summary of the points of discussion.
I work in a similar way as Stéphane describes.

--Hannes

On 5/2/18, Stéphane Rollandin [hidden email] wrote:

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?

I use projects mostly as virtual desktops where I keep different aspects
of my work (be it development or music composition) more or less cleanly
separated.

When I realize that what I'm working on is not anymore in the meant
scope of the current project, I create a new project and dispatch all
workspaces, browsers and other tools (including homemade ones such as
musical editors) that live in the current (usually crowded) World to the
world of that project.

So I only deal with top-level morphs, and as I said earlier I added an
item in their red handle menu to easily send them away (usually several
morphs in a row). I also have another item for sending a morph copy to
another project, but I use this one much less often.


Stef

Thanks for this, Bob!