[sugar] Sharing data between activities.

[Eben Eliason]

>
> > Installing a bunch of example images with the activity bundle sounds
> > like a really bad idea to me, given our space limitation
> > (independently from the fact that you want them share between multiple
> > activities). Why don't we just make these available separately, as a
> > content bundle (.xol)? That way kids can install and uninstall these
> > when they want through the journal.
>
> Well, this seems to ignore the major intention of delivering initial
> content on the system - getting the kids to learn by example. How
> should they know they have to install something before they can start
> learning?


I think one difference here is the predominance of the format in question.
 Images, video, audio, and other "primitive types" of media will not be in
short supply, and in fact the kids will be producing these in great quantity
themselves.  As such, there is no shortage of images that might be dropped
on one of these puzzles.

Tutorials and examples, on the other hand, provide us with an unknown format
for an activity that may or may not be readily discoverable without them in
the first place.  This is a different concern, and we definitely need to
support this as well.

Clicking an icon and getting an empty document was one of the major
> problems Etoys had before the OLPC version. The current initial Etoys
> project (our "launch" screen with the 5 cloud buttons) at least
> presents a couple of choices, and links to other projects that
> demonstrate various parts of the system.
>
> How would that be done if the examples have to be installed first?
> Even leaving aside the problem of security concerns forbidding direct
> linking to objects in the journal, how *do* we provide a seamless
> introduction?


Well, we've talked about this a lot, and the proposal on the table at the
moment is to allow instantiating new objects/documents/projects with
examples.  That is, when opening a new Etoys project, the user may have the
option to select an empty project or any from a list of examples. This
option should only appear once, upon instantiation, at which point the
selected project becomes the object represented by the activity instance;
more examples could be launched by creating new instances.

The best way to understand this is to consider each running instance as an
object itself, ignoring the notion of applications which open a bunch of
separate files, perhaps even at the same time.  Allowing any form of "open"
functionality that isn't an import function (such as importing an image into
the current write document) actually "swaps" the object represented by the
running instance, which we want to avoid.  By making this a parameter of the
creation of the instance, this dilemma goes away.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070827/dc394fee/attachment-0001.htm