Sascha, In regard to my comment: > [...] it would store meta info for the books, as well as the content > type of the book (which the MIME type by itself would not be enough to > do). what I meant was that there are some MIME types mapped to more than one Activity. For instance, the MIME type text/plain is used by Read Etexts but also by the Write activity. application/zip is used by Etoys, View Slides, and Read Etexts. Because of this you cannot simply click on an entry in the Journal that has one of these MIME types to resume it. You need to specify which Activity you want to open it with. You need to do this every single time, and it's annoying. The real answer to this is not what I talked about in that email. The real answer is to implement "Unified Bundles" which package books up like Activities and have a configuration file that says how they should be opened: as a bunch of images in a Zip file, as a plain text file, etc. That way when I try to read a Gutenberg text file I don't have to deal with opening Write by mistake, and when I'm viewing a comic book I don't have to deal with opening Etoys by mistake.
Journal entries created by an Activity are always resumed by that Activity. It's the Activities that DON'T create their own Journal entries that have this issue. This problem makes Sugar less usable as a platform for reading ebooks, which is a shame because ebook reading could be a killer app for Sugar and the XO otherwise. Unified Bundles were proposed a couple of weeks ago as a way of dealing with these problems and others. I regards to your point on the SD card, I would love for it to act as a second Journal. Failing that, it should have a view in the Journal that communicates to the user that it is NOT a second Journal. Maybe a Windows Explorer kind of view that shows subdirectories, etc. The current situation where it LOOKS like a Journal but doesn't ACT like one (no metadata saved, etc.) is annoying. And whatever you do with the SD card the USB thumb drive should definitely have an Explorer look and feel. It is something foreign to Sugar and it should look that way. James Simmons Sascha Silbe wrote: > > Following up on a discussion on iaep... > > On Wed, Apr 29, 2009 at 04:10:59PM -0500, James Simmons wrote: > >> The SD card cannot do everything the Journal can do, [...] > This is something that we should fix. The way the SD card / USB stick > support works (in Sugar 0.82.1 on the XO) has bugged me for the past > few days (e.g. only FAT filesystems will be usable from inside the > Journal). > Maybe it could work roughly like the following (just a brain dump): > - automount everything, with UUID-based access (/media/by-uuid/<uuid>) > in addition to the current name-based access > (/media/<name>[_<increment>]) > - use "flag files" (empty file with well-known name, e.g. > ".sugar_datastore_ignore") on the filesystem to filter it out from the > Journal (so it doesn't index/show the wwwoffle cache) > - let the user unmount Journal-monitored filesystems from the command > line (regular umount doesn't work because the fs is busy) > > This way SD cards and USB sticks can be used as both a Journal > expansion and low-level storage expansion (using symlinks to > /media/by-uuid/...), even in parallel (on the same device). > > [book reading activity] >> [...] it would store meta info for the books, as well as the content >> type of the book (which the MIME type by itself would not be enough >> to do). > What do you mean with "content type" if the MIME type is not enough > (but apparently closely related)? > > CU Sascha > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
