[Etoys-notify] [JIRA] Updated: (SQ-119) Saving and Loading of Project with sub-Projects

jira at immuexa.com jira at immuexa.com
Wed Apr 29 12:54:50 EDT 2009

     [ http://tracker.immuexa.com/browse/SQ-119?page=all ]

Scott Wallace updated SQ-119:

    Fix Version: M2: second alpha (june)
                     (was: triage)

The existing "stubbing" mechanism is workable only if the subprojects being referred to are already present in the user's directory.  I think that a true solution to the need would involve having a general way that a ProjectViewMorph could refer to another project by an arbitrary url, which would be followed when the user actually clicked on the link. If anyone can make this work in general, it would be a great boon, so let's put this into M2 for now and see if anyone will take it on.  More realistically, this will probably end up in the "someday" bin.

> Saving and Loading of Project with sub-Projects
> -----------------------------------------------
>          Key: SQ-119
>          URL: http://tracker.immuexa.com/browse/SQ-119
>      Project: squeakland
>         Type: Feature
>   Components: etoys
>     Reporter: team
>     Priority: Eventual
>      Fix For: M2: second alpha (june)

> From TRAC Ticket #7559 (dmoco)
> (The extensive interchange on this TRAC ticket is reproduced below for historical interest)
> As a test I created a "parent" project, entered and created two "child" projects (also entering each of these to ensure fully initialised). Then from within the parent I used the "World menu/ projects.../ save project on local file only". Then deleted children and parent.
> On reloading parent project the children appear but when one is clicked there appears a third (child) project view. In this one there is the sugar nav bar with a red rectangle on top. This turns out to be a Text morph containing red text: "Welcome to a new project - ChildProject1". This is obviously a bug but what about restoration of the original child project/s?
> Project file attached for parent containing two sub-projects.
> (dmoco) "sugar nav bar with a red rectangle on top" was due to problem reported in #7519 and unrelated to this ticket.
> Regarding project saving/loading: could someone confirm that saving a project hierarchy is not supported?
> (scott) Yes, unfortunately. Saving a project hierarchy is not supported.
> (dmoco) OK, thanks. Conscious design decision or lack or time/resources?
> Following advice on Etoys mailing list I am rechecking some of my bug reports using the image from etoys-image-and-pr.zip with latest updates (previously I had been using etoys-dev also with latest updates, which makes me wonder why they should be acting differently). The problem detailed in this trac report, ie, getting a third project window appears fixed.
> Scott, I am going to summarise my findings regarding "projects" on the mailing list and leave it to yourself and others to decide if any points constitute bugs/conflicts/confusion.
> (scott) Lack of time/resources. Certainly not a conscious design decision!
> (yoshiki) Oh, I see. If you would like to save all together, it doesn't work in that way. But I thought it was more a conscious decision. (It was there when I'm aware of Etoys.)
> Take the "Gallary of Projects" as an example. It had these sub projects and saved. Upon saving, only the stubs of these sub projects are really saved. And you load the parent project and click on the thumbnail of the sub project, it trys to load the project from the disk.
> (dmoco) Just to reiterate what I have said recently on the mailing list, I am looking generally at things from the POV of a new users, what may/ may not be reasonable expectations and also consistency of functionality. Or put another way, any gotcha's they may encounter. I just want to make clear I am not taking a swipe at the decisions and effort you guys make and I fully appreciate that your priorities are children, education and the XO. Personally I am extremely grateful for all you have done and are doing. And feel free to shoot down any of my assumptions, which I fully accept may be wrong. So with this in mind...
> - Assumption: a new user is not expected to use the World menu (or by implication the "projects" menu/s). This is based on the fact that the World menu only appears accessible through alt-W. I know many/all things are configurable but I am assuming this is intentional on your part. If true I am not disagreeing with this!
> - Novice users are expected to navigate projects using project-view morphs and the "back" button in the Sugar nav. As a consequence they have no direct access to the project hierarchy and cannot jump indiscriminately from one project to another.
> - New projects can only be created from the "Etoys Activity" project. Intentional? Means users cannot create their own hierarchies. IMHO creating hierarchies is something that should be possible even for a novice and emphasised as good way of organising ones activities (even/especially where children are concerned).
> - I can see the potential for tangled hierarchies and the implications if saving of sub-projects was to be implemented (but not insurmountable). I assume there would be other issues related to where projects are stored/ loaded from.
> - When saving a project that contains sub-projects, there is nothing to indicate that the sub-projects will *not* also be saved. Maybe a pop-up reminder?
> - In etoys-dev it is not possible to delete a project containing sub-projects and there is a pop-up msg to this effect. There is no such restriction or msg in etoys-image-and-pr where the user is simply warned that *all* project contents will be deleted, except this is not true...
> - In the case of sub-projects they are not deleted and are instead re-parented to their grandparent but now do *not* have any project-view icons. End state being that these project/s are now effectively invisible to the novice and also still consuming resources that the user will be unaware of.
> - If the user deletes a parent project *without* deleting sub-projects: reloading parent does not re-parent children, although project-views in parent still function as expected. Remember I am just stating my findings and in this case before I was aware that saving hierarchies is not possible.
> - If the user deletes sub-projects before reloading parent: after reloading parent and clicking on a child project the hierarchy is re-established. As expected but still different from previous scenario. A minor issue here is before a sub-project is actually loaded the balloon help says "...(on server)" which is not true when only stored locally. Also begs the question (most likely due to my own lack of knowledge) about how local/server-based mechanism works? For instance: same-named local/remote projects supported and if so do I have a choice?
> To state my own preference, I would like to be able to save a project hierarchy in one go and I believe this is what others would expect to be able to do.
> Sorry if this reply was longer than expected :-)
>   Changed 7 months ago by dmoco ¶
> Browsing the Project class I noticed there is storeAllInSegments which looked promising. It calls Project>>storeSegment but this eventually produces a DNU trying to call LargePositiveInteger>>leadChar. Problem appears to be in the Word Array representation of the image segment:
> a WordArrayForSegment(1929386342 122041031 208 236 336 400 452 504 ...
> (bert) I don't think we can do anything about this for the 8.2 release.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

More information about the Etoys-notify mailing list