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

Reply via email to