<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Take my specific use case: I have a Slider Puzzle and a Jigsaw Puzzle.<br>These are two separate activities, but both have bundled images, the
<br>same bundled images. It is somewhat desirable to share the images across<br>these activities (and other on the make) because not only of the space<br>constraint but also to allow for easier upgrading of the image set, not
<br>being dependent of applying the upgrade to all activities (assuming<br>that's the only case).</blockquote><div><br class="webkit-block-placeholder"></div><div>Well, I see it being perfectly acceptable to bundle half a dozen or so images in each activity, the same or otherwise. I would say that, with a camera on the laptops and an emphasis on creation, the more common case should be to let the kids drop a drawing of their house or a picture their family anyway, so bundling a large set of default images shouldn't be necessary in the first place. Take advantage of the tool and the kids' desires to create things.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As for the code sharing, well, it just makes sense to me to keep it<br>packaged that way, but since space is of much lower importance here, I
<br>could easily create a common code repository and just import that on<br>each activity, thus keeping things in sync. Just thinking out loud...</blockquote><div><br class="webkit-block-placeholder"></div><div>That would work. The point is, I might for instance get really frustrated by slide puzzles; I could think they are impossible and never want to open it a second time. Jigsaws, on the other hand, I may love. By keeping these separate, I can simply delete the slide puzzle activity, thus saving all that space, including that the shared code and images would take up anyway.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Still have the shared 'My Own Image' problem though. This is a<br>collection of (links to) images the user has selected from the
<br>filesystem. Assuming the user will be allowed to upload files from a<br>thumb drive or the internet into the XO's journal, I can dump the<br>filesystem access. But for keeping the images I need a single, shared<br>
list of objects to be found on the datastore. This could, I guess, be<br>itself an object in the datastore, assuming I can create a single<br>object, searchable by some id and metatype, which is not presented in<br>the Journal.
</blockquote><div><br class="webkit-block-placeholder"></div><div>I think I'm missing an aspect of this argument. First, you will have access to the filesystem via an "import object" type palette (provided by the OS itself via an API being worked on). Furthermore, you'll be able to provide a list of MIME types that you want to accept, so that the object chooser presents only a list of images, and nothing else. In that way, you will be able to ask for references to images the user selects from their collection. You should also certainly support drag'n'drop of images directly onto the puzzle.
</div><div><br class="webkit-block-placeholder"></div><div>I don't really think it's necessary to keep a list of these images though. I'll take more photos, make more drawings, and get tired of the old ones eventually. Also, it's just as easy to reselect one from before, via the same palette, than to require some sort of file manager within the slide puzzle activity itself for tracking those. You could likely let the slide puzzle be good at puzzling, and leave the file/list management stuff out completely.
</div><div><br class="webkit-block-placeholder"></div><div>I especially don't see any reason that the jigsaw puzzle should need to know what image I placed in the slide puzzle activity. There might be some instances where the lack of shared space will take more effort to overcome, but I think these are two separate activities and shouldn't ever need to know what each other are doing.
</div></div><br><div>- Eben</div><div><br class="webkit-block-placeholder"></div><div>PS. I'm also aware that some of this may not have been known to you at all. Things are moving fast, and documentation is a bit behind, but I assure you these things, such as a pretty cool file importers for specific types of media, will come down the road.
</div>