There is a discussion underway on squeak-dev about refactoring Projects. Since we intend to eventually use this for Etoys, it would be good to join the fun now rather than deal with the fallout later.
Thread starts here: http://lists.squeak.org/pipermail/squeak-dev/2009-November/141294.html
E.g. I'm not sure if in Etoys we want projects without a project view as Andreas suggested below.
- Bert -
Begin forwarded message:
From: Andreas Raab andreas.raab@gmx.de Date: 25. November 2009 06:33:57 MEZ To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: MVC-Morphic refactoring, review needed Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
David T. Lewis wrote:
Instead, what we should do is to make it so that deletion of projects is explicit, via the menu action called "close project" (with confirmation etc). Then you can get rid of all of that logic - it's always safe to delete a project view since the underlying project will only be deleted when you explicitly choose to.
I'm not sure I understand. Are you thinking of a menu action in the world menu of the current project, or a menu action in the window menu of the view on the project? (Or something that already exists that I am overlooking?)
The former. I think the "Projects" menu should say: New Project Load Project Save Project Close Project and "Close Project" is the only action that ever nukes the project for real. Project views are just project views, they can be deleted without any further implications for the original project.
I think that it is still necessary to ensure that the project is finalized when the last open view has been closed, at least in the case of a Morphic project with Players and Wonderlands (I don't know what the issues are, but the cleanup code must be there for a reason).
My point is that a project can exist without any currently visible project views. The project remains accessible via the "jump to project" menu and its "primary" reference is through Project>>allProjects.
So if the user closes the last open view on a project, I expect that we still want the project to be automatically finalized, and we would not want finalization to occur unless the view being closed was the last open view on that project. Does that sound right?
Not quite (from my perspective - I'm not saying you have to agree :-) Views are views, they're not the real thing. We could conceivably offer to close the project when the last view is closed, but going forward I think we'll end up with more projects that have no dedicated views and are only accessible via places like the "jump to" menu.
Cheers,
- Andreas
On 2009-11-25 10:59, Bert Freudenberg wrote:
There is a discussion underway on squeak-dev about refactoring Projects. Since we intend to eventually use this for Etoys, it would be good to join the fun now rather than deal with the fallout later.
Thread starts here: http://lists.squeak.org/pipermail/squeak-dev/2009-November/141294.html
E.g. I'm not sure if in Etoys we want projects without a project view as Andreas suggested below.
- Bert -
The project views could be stored in the FileList/ProjectLoader and fetched from the nearest location. Then all/most portals to other worlds would have the same location.
I guess we have to deal with this issue if we want to use Etoys as a SlideShow/ PowerPoint thing eg. each page of a slide would be a project/page. Also a merge of BookMorph and Project when presenting would be interesting.
Karl
Begin forwarded message:
From: Andreas Raabandreas.raab@gmx.de Date: 25. November 2009 06:33:57 MEZ To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: MVC-Morphic refactoring, review needed Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org
David T. Lewis wrote:
Instead, what we should do is to make it so that deletion of projects is explicit, via the menu action called "close project" (with confirmation etc). Then you can get rid of all of that logic - it's always safe to delete a project view since the underlying project will only be deleted when you explicitly choose to.
I'm not sure I understand. Are you thinking of a menu action in the world menu of the current project, or a menu action in the window menu of the view on the project? (Or something that already exists that I am overlooking?)
The former. I think the "Projects" menu should say: New Project Load Project Save Project Close Project and "Close Project" is the only action that ever nukes the project for real. Project views are just project views, they can be deleted without any further implications for the original project.
I think that it is still necessary to ensure that the project is finalized when the last open view has been closed, at least in the case of a Morphic project with Players and Wonderlands (I don't know what the issues are, but the cleanup code must be there for a reason).
My point is that a project can exist without any currently visible project views. The project remains accessible via the "jump to project" menu and its "primary" reference is through Project>>allProjects.
So if the user closes the last open view on a project, I expect that we still want the project to be automatically finalized, and we would not want finalization to occur unless the view being closed was the last open view on that project. Does that sound right?
Not quite (from my perspective - I'm not saying you have to agree :-) Views are views, they're not the real thing. We could conceivably offer to close the project when the last view is closed, but going forward I think we'll end up with more projects that have no dedicated views and are only accessible via places like the "jump to" menu.
Cheers,
- Andreas
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 25.11.2009, at 18:48, Karl Ramberg wrote:
On 2009-11-25 10:59, Bert Freudenberg wrote:
There is a discussion underway on squeak-dev about refactoring Projects. Since we intend to eventually use this for Etoys, it would be good to join the fun now rather than deal with the fallout later.
Thread starts here: http://lists.squeak.org/pipermail/squeak-dev/2009-November/141294.html
E.g. I'm not sure if in Etoys we want projects without a project view as Andreas suggested below.
- Bert -
The project views could be stored in the FileList/ProjectLoader and fetched from the nearest location. Then all/most portals to other worlds would have the same location.
I guess we have to deal with this issue if we want to use Etoys as a SlideShow/ PowerPoint thing eg. each page of a slide would be a project/page. Also a merge of BookMorph and Project when presenting would be interesting.
Karl
More fun with projects:
http://lists.squeak.org/pipermail/squeak-dev/2009-November/141382.html
Interesting stuff! And positive responses from squeak-dev folks so far, they generally like where this is going.
- Bert -
Begin forwarded message:
From: Andreas Raab andreas.raab@gmx.de Date: 26. November 2009 05:25:39 MEZ To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Embracing Projects Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Folks -
I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more.
The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects)
And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects.
Thoughts?
Cheers,
- Andreas
Bert Freudenberg wrote:
On 25.11.2009, at 18:48, Karl Ramberg wrote:
On 2009-11-25 10:59, Bert Freudenberg wrote:
There is a discussion underway on squeak-dev about refactoring Projects. Since we intend to eventually use this for Etoys, it would be good to join the fun now rather than deal with the fallout later.
Thread starts here: http://lists.squeak.org/pipermail/squeak-dev/2009-November/141294.html
E.g. I'm not sure if in Etoys we want projects without a project view as Andreas suggested below.
- Bert -
The project views could be stored in the FileList/ProjectLoader and fetched from the nearest location. Then all/most portals to other worlds would have the same location.
I guess we have to deal with this issue if we want to use Etoys as a SlideShow/ PowerPoint thing eg. each page of a slide would be a project/page. Also a merge of BookMorph and Project when presenting would be interesting.
Karl
More fun with projects:
http://lists.squeak.org/pipermail/squeak-dev/2009-November/141382.html
Interesting stuff! And positive responses from squeak-dev folks so far, they generally like where this is going.
That's cool! I absolutely like what is going on there!
Rita
- Bert -
Begin forwarded message:
From: Andreas Raab andreas.raab@gmx.de Date: 26. November 2009 05:25:39 MEZ To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Embracing Projects Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Folks -
I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more.
The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects)
And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects.
Thoughts?
Cheers,
- Andreas
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org