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
- 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"
On 4/30/18 12:44 PM, Chris Cunningham wrote:
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 Bob, Tony,
On Mon, Apr 30, 2018 at 10:37 AM, Bob Arning arning315@comcast.net wrote:
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
This did it (the code in an explorer). The flaps probably would have
worked - just didn't want to use it that way. Not sure why.
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.
Tony, - blog post: http://www.lshift.net/blog/2005/08/19/how-hard-can-it-possibly-be/ Yes, that is what I was looking for, although Bob's snippit seems to be cleaner. Maybe a menu item in the halo to move top level morphs between project (or, even, NOT top level morphs, but that could be weird).
Thank you both, cbc
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)
On 4/30/18 5:14 PM, Chris Cunningham wrote:
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.
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-...
- squeak-dev posting with changeset: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/093538.ht...
Cheers, Tony
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
Hi.
On Tue, May 1, 2018 at 6:10 AM, Stéphane Rollandin lecteur@zogotounga.net wrote:
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
<snip>
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?
-cbc
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?
On 5/1/18, Bob Arning arning315@comcast.net 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 arning315@comcast.net 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; tim@rowledge.org; 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
On 1 May 2018, at 18:16, tim Rowledge tim@rowledge.org wrote:
On 01-05-2018, at 9:51 AM, Bob Arning arning315@comcast.net 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: NNI: Neglect Next Instruction
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.
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.
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 lecteur@zogotounga.net 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
Given that you just switched from the target project into the source project, execute this in the Morph's inspector:
Best, Marcel Am 02.05.2018 11:49:09 schrieb H. Hirzel hannes.hirzel@gmail.com: 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 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
On May 2, 2018, at 4:11 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Given that you just switched from the target project into the source project, execute this in the Morph's inspector:
<image.png>
April 1st was last month...
Best, Marcel
Am 02.05.2018 11:49:09 schrieb H. Hirzel hannes.hirzel@gmail.com:
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 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
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.
On 5/2/18 5:48 AM, H. Hirzel wrote:
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 lecteur@zogotounga.net 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!
I work in a similar way to what other people describe. I keep my work separated into different Morphic projects. When I find myself starting to digress, I start a new project, and move the related inspectors/browsers/workspaces into it. However, I simply do this by dragging-and-dropping morphs into the project's snapshot/thumbnail morph*. The thumbnail will say "GOT IT!" and contain a copy of the morph.
This approach has caveats:
(1) the snapshot/thumbnail morph will only accept drops if its project has been entered and exited, erm, recently (?). (2) this technique creates a copy of morphs rather than moving them. (3) this exposes what I believe to be a bug: the thumbnail bitmap/form will not always show the most recent visual representation of the project contained inside.
I too have wanted a halo menu item to send a morph to another project. I like the possibility of having a "drop zone" morph as a teleporter ... though the project snapshot/thumbnail morph can work in this way.
I am asking myself now what would happen if I dragged a project snapshot/thumbnail morph into a shared flap so I could move it between projects: tested, done. it works. So: one way to move morphs between projects is to move a project's thumbnail/snapshot morph between projects, and drag-and-drop morphs into it. Just be aware that it will probably only work if the project has been entered and exited "recently".
Best, Tim
* a SystemWindow/PasteUpMorph with a model of MorphicProject
On May 2, 2018, at 5:09 AM, Bob Arning arning315@comcast.net wrote:
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.
On 5/2/18 5:48 AM, H. Hirzel wrote:
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 lecteur@zogotounga.net mailto:lecteur@zogotounga.net 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
<DropZone.02May0805.cs>
On 5/2/18 10:44 AM, Tim Johnson wrote:
Thanks for this, Bob!
I work in a similar way to what other people describe. I keep my work separated into different Morphic projects. When I find myself starting to digress, I start a new project, and move the related inspectors/browsers/workspaces into it. However, I simply do this by dragging-and-dropping morphs into the project's snapshot/thumbnail morph*. The thumbnail will say "GOT IT!" and contain a copy of the morph.
This approach has caveats:
(1) the snapshot/thumbnail morph will only accept drops if its project has been entered and exited, erm, recently (?).
I think the only real limitation is that the Project actually be in memory. PVM's can represent projects yet to be loaded. Oh, and that it be a Morphic project that has been initialized.
(2) this technique creates a copy of morphs rather than moving them.
Yes.
(3) this exposes what I believe to be a bug: the thumbnail bitmap/form will not always show the most recent visual representation of the project contained inside.
More of an old-fashioned, conservative approach. Update it only when leaving the project.
I too have wanted a halo menu item to send a morph to another project. I like the possibility of having a "drop zone" morph as a teleporter ... though the project snapshot/thumbnail morph can work in this way.
I am asking myself now what would happen if I dragged a project snapshot/thumbnail morph into a shared flap so I could move it between projects: tested, done. it works. So: one way to move morphs between projects is to move a project's thumbnail/snapshot morph between projects, and drag-and-drop morphs into it. Just be aware that it will probably only work if the project has been entered and exited "recently".
Best, Tim
- a SystemWindow/PasteUpMorph with a model of MorphicProject
On May 2, 2018, at 5:09 AM, Bob Arning <arning315@comcast.net mailto:arning315@comcast.net> wrote:
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.
On 5/2/18 5:48 AM, H. Hirzel wrote:
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 Rollandinlecteur@zogotounga.net 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
<DropZone.02May0805.cs>
With EToyProjectHistoryMorph you can drag out the project view of any project and drop your morph on that.
Best, Karl
On Wed, May 2, 2018 at 4:44 PM, Tim Johnson digit@sonic.net wrote:
Thanks for this, Bob!
I work in a similar way to what other people describe. I keep my work separated into different Morphic projects. When I find myself starting to digress, I start a new project, and move the related inspectors/browsers/workspaces into it. However, I simply do this by dragging-and-dropping morphs into the project's snapshot/thumbnail morph*. The thumbnail will say "GOT IT!" and contain a copy of the morph.
This approach has caveats:
(1) the snapshot/thumbnail morph will only accept drops if its project has been entered and exited, erm, recently (?). (2) this technique creates a copy of morphs rather than moving them. (3) this exposes what I believe to be a bug: the thumbnail bitmap/form will not always show the most recent visual representation of the project contained inside.
I too have wanted a halo menu item to send a morph to another project. I like the possibility of having a "drop zone" morph as a teleporter ... though the project snapshot/thumbnail morph can work in this way.
I am asking myself now what would happen if I dragged a project snapshot/thumbnail morph into a shared flap so I could move it between projects: tested, done. it works. So: one way to move morphs between projects is to move a project's thumbnail/snapshot morph between projects, and drag-and-drop morphs into it. Just be aware that it will probably only work if the project has been entered and exited "recently".
Best, Tim
- a SystemWindow/PasteUpMorph with a model of MorphicProject
On May 2, 2018, at 5:09 AM, Bob Arning arning315@comcast.net wrote:
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.
On 5/2/18 5:48 AM, H. Hirzel wrote:
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 lecteur@zogotounga.net lecteur@zogotounga.net 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
<DropZone.02May0805.cs>
On May 2, 2018, at 5:09 AM, Bob Arning arning315@comcast.net wrote:
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.
Yes, I like drag & drop too. But I would like to be able to drag&drop onto the project morph itself. That way we could provide a "projects" morph that showed all the projects in the system, and allow selecting the morph thumbnails one sees in each project morph, and then be able to directly manipulate and drag any top-level morph from any project to any other. Given a multiple selection convention we could batch, although in my own use I typically only need to move one of two morphs.
On 5/2/18 5:48 AM, H. Hirzel wrote: 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 lecteur@zogotounga.net 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
<DropZone.02May0805.cs>
EToyProjectHistoryMorph shows all the projects
On Thu, May 3, 2018 at 3:50 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 2, 2018, at 5:09 AM, Bob Arning arning315@comcast.net wrote:
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.
Yes, I like drag & drop too. But I would like to be able to drag&drop onto the project morph itself. That way we could provide a "projects" morph that showed all the projects in the system, and allow selecting the morph thumbnails one sees in each project morph, and then be able to directly manipulate and drag any top-level morph from any project to any other. Given a multiple selection convention we could batch, although in my own use I typically only need to move one of two morphs.
On 5/2/18 5:48 AM, H. Hirzel wrote:
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 lecteur@zogotounga.net lecteur@zogotounga.net 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
<DropZone.02May0805.cs>
On May 3, 2018, at 6:54 AM, karl ramberg karlramberg@gmail.com wrote:
EToyProjectHistoryMorph shows all the projects
Then I vote for renaming it AllProjectsMorph, moving it to Tools-Morphic or some such, adding if yo the Tools menu and making sure one can select top-level SystemWindow morphs within it and drag and drop them either onto the desktop or to other project thumbnails within it.
On Thu, May 3, 2018 at 3:50 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 2, 2018, at 5:09 AM, Bob Arning arning315@comcast.net wrote:
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.
Yes, I like drag & drop too. But I would like to be able to drag&drop onto the project morph itself. That way we could provide a "projects" morph that showed all the projects in the system, and allow selecting the morph thumbnails one sees in each project morph, and then be able to directly manipulate and drag any top-level morph from any project to any other. Given a multiple selection convention we could batch, although in my own use I typically only need to move one of two morphs.
On 5/2/18 5:48 AM, H. Hirzel wrote: 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 lecteur@zogotounga.net 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
<DropZone.02May0805.cs>
As karl mentioned, there is such a thing, but perhaps specialization is useful. Attached is an update to DropZoneMorph which can create drop zones (with thumbnail) for all morphic projects, with the extra feature that dropped morphs are centered in the destination world to make them easy to find.
Also, it's not just top-level morphs -- here is a class list from a browser dropped into a different project:
On 5/3/18 9:50 AM, Eliot Miranda wrote:
On May 2, 2018, at 5:09 AM, Bob Arning <arning315@comcast.net mailto:arning315@comcast.net> wrote:
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.
Yes, I like drag & drop too. But I would like to be able to drag&drop onto the project morph itself. That way we could provide a "projects" morph that showed all the projects in the system, and allow selecting the morph thumbnails one sees in each project morph, and then be able to directly manipulate and drag any top-level morph from any project to any other. Given a multiple selection convention we could batch, although in my own use I typically only need to move one of two morphs.
On 5/2/18 5:48 AM, H. Hirzel wrote:
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 Rollandinlecteur@zogotounga.net 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
<DropZone.02May0805.cs>
NetMorph on Squeak map was a package to send morph to anywhere :-)
Best, Karl
On Wed, May 2, 2018 at 10:25 AM, Bob Arning arning315@comcast.net wrote:
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 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.
and EToySenderMorph can send a morph to another computer
On 5/2/18 3:05 PM, karl ramberg wrote:
NetMorph on Squeak map was a package to send morph to anywhere :-)
Best, Karl
On Wed, May 2, 2018 at 10:25 AM, Bob Arning <arning315@comcast.net mailto:arning315@comcast.net> wrote:
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> <mailto:arning315@comcast.net> wrote:a Flap would do thatYes 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.
In image Nebraska also. Need check in 6.0 or I should say in 5.2
On 02/05/2018, 16:05, "karl ramberg" karlramberg@gmail.com wrote:
NetMorph on Squeak map was a package to send morph to anywhere :-)
Best, Karl
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" cunningham.cb@gmail.com 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.
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Chris Cunningham -
Edgar J. De Cleene -
Eliot Miranda -
Francisco Garau -
H. Hirzel -
karl ramberg -
Marcel Taeumel -
Stéphane Rollandin -
Tim Johnson -
tim Rowledge -
Tony Garnock-Jones