[sugar] Sharing data between activities.

[Eben Eliason]

>
> >> - The images bundled are art done by kids on the MaMaMedia site. They
> >> are examples and can be trimmed down considerably, but they are also
> >> reasons to be proud for the kids that did them, so I guess that if we
> >> can keep the whole bunch, we will.
> >>
> >
> > 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 done Marco!  I came up with this in bed last night and thought it hit
the nail on the head, excited to suggest it, and it was already here waiting
for me.  I agree with this idea. If the media is not an integrated part of
the activity itself, then a content bundle makes a lot of sense, and
eliminates the redundant data and other problems.

Well, that is by far the best idea I've heard on the shared content
> issue! So I could provide the data as a separate bundle and kids use it
> from the Journal. And, if I can get my way with tagging and listing
> stuff from the datastore programatically I can even keep the categorized
> view in the activities...


I have to apologize as well, since I really haven't had time to test out all
of the various activities that are under development.  It's truly fantastic
that so many of the points I suggested in my little example are already
underway!

That said, the one point I'm going to continue to fight for is to rid the UI
for these activities of any internal list of images altogether.  The Journal
is perfectly suited for tagging, starring, searching and filtering
everything (and will be accessible through a chooser), so I really don't see
a reason to require this bar.  Let the activity be solely about actually
doing the puzzle, and let the management of images etc. be left up to our
standard object chooser, which will be consistent, powerful, and secure and
save you the coding trouble and screen real estate.

Like I said, each puzzle is it's own object, so each puzzle should really
only need to have a reference to its own single image.  This will give you
more space, too, so that you can use the entire screen area for putting the
puzzle together.  The list of files is unneeded fluff, since chances are I'm
not going to change the picture on a puzzle I've half completed.  If I did
decide to do that I might as well just create a new puzzle instance and
start there, right?

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070824/2c3bbabf/attachment.htm