[sugar] Sharing data between activities.

[Eben Eliason]

>
> But if you don't dislike any of the now 2, but potentially more
> activities that share images between them, you'll end up having a lot of
> wasted space, but of course the file hashing and linking would take care
> of that.


What space would be wasted?  Like I said, I think you only need a few images
as a base.  For these activities you're talking about, the content of the
image doesn't seem to be essential to the activity itself.  You could ship 3
images or so with each and let the kids provide the rest.



> Think of 'My Own Images' like Bookmarks are on a browser. You don't
> store the content, you don't see the whole set of available data, you
> just mark them as 'cool'. Maybe there is tagging in the datastore
> objects and I never crossed it? That would work really great and without
> ever needing to do special kungfu or corner cases.


But bookmarks are created from the browser because that's where you go to
browse pages.  Kids can tag and star their photos when they take them.
 Adding a complicated file structure for managing photos inside what is
otherwise a very lightweight activity shouldn't be necessary.  The Journal
does in fact depend heavily on the notion of tagging, and as mentioned
there's even an integrated "starring" feature which let's the kids identify
their favorite things within it.

It's a 'personal preference' thing, the bookmarks. You really like that
> image of an XO completely dismantled, so you use it for everything...
> but then again, maybe user tags would work better? If the user feels so
> inclined, he/she/it can tag images and apply that as a filter when
> selecting an 'external' image.
>
> There is an extra piece of information I didn't give you, which is the
> fact that images are categorized. I have a folder that holds folders
> (categories) that holds images. You have a list of categories presented
> to you and a separate widget that holds one image of the selected
> category and has left/right arrows to walk through the other. 'My Own
> Images' is a special category.


Again, I still think this is entirely over engineering the problem.  There
should be a few base images (even just one?) and no need for this complex
hierarchy or record of images (or a sidebar at all?). We've also been
eliminating hierarchy in many cases, and I think that the "My Own Images"
category is really what it's all about.  The laptops are going to ship with
lots of materials and a virtual library where the kids can find photos (and
videos, sounds, texts, etc) of anything they want, so there's not much need
for each activity to bundle their own library of media.  When I want to do a
different puzzle, I could select a new one from the Journal (via drag'n'drop
or a chooser).  The chooser itself will only show me images in the first
place, likely with thumbnails, and it will have a search and filter field so
I can quickly type "cat" (instead of browsing through categories) and select
the "starred" filter to find my favorite photo of my cat in a flash.

Since we are changing the filesystem and its access so drastically, we're
also dedicated to making interactions with it meaningful and simple for
developers so that they don't have to jump through hoops to do their own
management unless it's essential to the activity.  For the most part, the
more we can take advantage of these common choosers and the idea of
tagging/filtering the stronger the whole system will be on the whole.


As another small tangent, the laptops depend on the notion of sessions,
especially in the face of potential collaboration.  As such, any management
except that around a particular session is unwanted.  Consider this use
case:  I open a jigsaw puzzle.  I start playing the default image of a fish
by myself, and then I share it and work on it with my friend for a while.
 We make some good progress.  Later I want to do my own, so I start a *new*
instance of the jigsaw puzzle (read this as I make a new jigsaw puzzle).  On
this one I drop a photo of my family, and I don't share it, because it's
personal.  Tomorrow, when I see my friend again, I go back to the Journal
and we open the puzzle of the fish we were working on yesterday, continuing
right where we left off.

You see, in this way I can have a bunch of different puzzles, each with it's
own image, and with a different set of participants, and being in a
different state of completion.  Each instance of the activity literally *is
a different puzzle* so to speak.  Even before collaboration is available,
this fits with our multi-instance/saved-session model, and it makes it more
clear why the image associated with any given instance of the activity is a
more intimate thing, and doesn't require the overhead of lists or managed
sets of files at all. (This is why I suggest only a single default
image...there's just one puzzle in the box, so to speak.)

Hopefully this example will turn your world upside down for a bit.  We look
at activities in a way that's quite different from many other platforms.  =)

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