Well, for the most part the single-document-per-activity-instance is the model. There are of course some exceptions to this rule. For instance, in a given web browsing session most people will visit a number of different websites; As such, the session is treated as the object within the Journal, and I could save one web session for basic entertainment, another for a paper I'm writing, etc. In that case, I don't think we actually need to directly expose the individual pages visited...we'd fill up the journal in a week.
<div><br class="webkit-block-placeholder"></div><div>Similar logic is true for an activity like Develop, which of course needs a number of source files, related resources, and an icon. This, again, gets wrapped into a single entry because the activity in development is treated as the object, and the remaining parts are subcomponents. This is a little bit trickier though, because you could of course want to edit the icon in another activity, or use a text editor with better syntax highlighting to edit the code, etc. At present, we don't really have a model for this.
<div><br><div>There are other cases, such as Record, where one takes a bunch of individual photographs. While, like the web session, I think that it's nice to treat these as a logical group - like a roll of film - I also realize that we absolutely have to offer these up individually. In the recent Journal designs, we're actually treating them as both: An individual photo entry appears in the Journal as it's taken, and when the "roll" is finished, it's stored in the journal as it's own entry as well, allowing you to maintain the grouping and play back the slideshow. To stretch the metaphor perhaps a little too far, I see this as reasonable because we're used to getting a bunch of photos in addition to a proof sheet (and the actual film).
</div><div><br class="webkit-block-placeholder"></div><div>As far as exposing hierarchy goes, one activity that we do think is much needed is a Bundle activity. This would basically be an unzipping activity, but it would have a little more work to do, because it would internally unzip a bunch of files, display them visually in any associated hierarchy, and allow the kids to copy individual files to or from the journal, and at the end zip it back up. They could also start with an empty bundle to create their own from scratch.
</div><div><br class="webkit-block-placeholder"></div><div>This still doesn't really solve Develop, which really calls for a way to invoke an "Edit with > Some other text activity" which would allow modification of the document from the desired activity, while listening for changes on those documents and functioning fully as an IDE when the "Run" button gets pressed, without need for moving around or zipping up the files. So maybe that's the answer: Perhaps a well devised system for spawning an activity of choice with an object within another activity is the way to go. If I edit a text file from Develop within Write, then saved changes should be pushed back to Develop, instead of the Journal. New entries wouldn't be created, but the changes would be wrapped up within the Develop object when it gets saved to the Journal itself. Is this a feasible solution?
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder">
</div><div><br class="webkit-block-placeholder"></div><div><div><span class="gmail_quote">On 7/12/07, <b class="gmail_sendername">Tomeu Vizoso</b> <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote:
</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I have been making this question since quite a bit of time and never got<br>an answer yet.<br><br>Eben, after doing something inside an activity, we could have created
<br>several photographs, we could have visited several web pages, etc. We<br>need to be able represent multiple objects inside a single journal entry<br>so they can be displayed, dragged or copied out, is this correct?<br>
<br>Ben, are you taking this in account when thinking about the architecture<br>of the Datastore?<br><br>Bert, how can a single eToys activity instance create several objects in<br>the journal? Wouldn't be everything inside a single eToys project?
<br><br>Thanks,<br><br>Tomeu<br><br>On Thu, 2007-07-12 at 09:25 -0400, Erik Blankinship wrote:<br>> This is a good question; access to individual photographs & videos in<br>> the journal have this problem.<br>>
<br>> <a href="http://dev.laptop.org/ticket">http://dev.laptop.org/ticket</a>/1758<br>><br>><br>> On 7/12/07, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>> If I understand the Sugar philosophy correctly, we won't have
<br>> multiple documents per activity. If we want to have multiple<br>> documents opened at the same time, these would be multiple<br>> instances<br>> of the same activity.<br>>
<br>> Is this the case?<br>><br>> And if so, what would one activity instance have to do to<br>> create a<br>> new instance?<br>><br>> - Bert -<br>><br>><br>
> _______________________________________________<br>> Sugar mailing list<br>> <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br>> <a href="http://lists.laptop.org">
http://lists.laptop.org</a>/listinfo/sugar<br>><br>> _______________________________________________<br>> Sugar mailing list<br>> <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br>> <a href="http://lists.laptop.org">
http://lists.laptop.org</a>/listinfo/sugar<br><br></blockquote></div><br></div></div></div>