[sugar] Multiple documents

[Eben Eliason]

>
> The idea is to have the notion of container entries that can contain
> other journal entries.


This does get tricky fast.  I think we'll need to discuss it briefly at our
design charrette on Tuesday.  There are certainly many cases where we could
use it, but I think a flat system where each entry is exposed individually
could still work.  I could be wrong; We'll have to try it to know how it
scales.

A Record entry would contain several entries, one for each photograph or
> video taken during that session.
>
> Resuming the container entry would open Record with that session
> resumed.
>
> Resuming any of the contained entries would resume Paint or another
> activity that registered for resuming that mime type.




> Also, individual entries as well as containers could be copied or
> dragged to the clipboard.
>
> Looks like in the case of etoys, if during the activity session were
> created more than one project, etoys could create a container session in
> the journal that contains one entry for each project.
>
> The container entry as well as the individual projects could be resumed
> by etoys.


I want to briefly ignore the technical point of "container" entries vs. "a
bunch of entries created by one activity instance" and talk about the
broader concept of sessions.  From my perspective, it makes sense to treat
each photograph as a separate entity in the Journal, apart from the meta
entry, the "roll of film."  On the other hand, I do not feel that this can
be said for Etoys.

For on thing, Etoys refers to things as projects, which already sound like
self contained bundles of sorts, much like a "sessions" in their own right.
 Combining several projects in one session just complicates matters, when
each can clearly be stored as its own entry within the Journal and resumed
at will.  This is, after all, the basic model we're after.  But when, then,
is it OK or even essential to break it?

I've been trying to come up with the rules which govern why I feel so
strongly about the difference between these types of activities, and it's
not an easy task.  That, and my lack of time to concentrate any time on the
HIG lately are part of the problem here, regardless of the API, and I
apologize.  Still, Ill try to make a stab at it here, in hopes that you can
all punch holes in my attempt.

I think there are two aspects which relate to my feeling on the matter.
First, the camera activity is -- forgive the pun -- a one shot activity.
 That is, the act of taking a single photo is immediate, and once that photo
is taken, it cannot be altered from within the activity itself.  It's a
constant from its time of creation, and its existence within the activity
session is a boolean value.  The core point here is that the object is not
the subject of continual modification; It does not have versions.  In a
space like Etoys provides, each project can be opened, modified, and resaved
at any time...each project has its own history.  In the photo activity, on
the other hand, the series of photos is the history of the roll of film, so
to speak.  This doesn't mean that you can't edit a single photo...you
certainly can, but not within the Camera activity, which is designed solely
for capturing the images.

That brings me to my second point, which is that some "primitive" types (and
probably some non-primitives as well) are naturally suited to being
available to a number of different activities.  I could draw on top of a
photo I took; I could place it within a paper I'm writing;  Etc.  I mostly
see this with media types, but I don't want to assume there aren't other
cases.  When a subcomponent of a session can be individually treated as its
own object *and opened within other activities* then I see it as something
that could deserve its own journal entry, separate from the session entry
itself.

As another example, consider the difference between these two sound
activities:  Record and SoundMix.  Both let you record sounds from the mic.
 Record is basically an audio capture device, of sorts;  It records sounds.
 SoundMix does this also, but provides a timeline and tools for adjusting
the pitch, cutting, splicing, phase shifting, and filtering;  It's a sound
editor.  Sounds captured in Record could be treated as separate entities.
They could, naturally, be imported into SoundMix.  The sounds recorded
within SoundMix, on the other hand, are created for the purpose of being
chopped/mixed, and are part of a larger project that can be continually
edited, and so a SoundMIx project really only needs to create a single
entry.

I hope that sheds a little bit of light on the whole idea.  I'd welcome any
comments or arguments on the matter.  Obviously its a tricky problem, and
one that developers are closer to than me.  Your feedback is the only way
we'll create a robust system.  Thanks.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070727/0c79bf79/attachment.htm