Re: [Sugar-devel] Book bundles and Read
On Sat, Aug 1, 2009 at 7:47 AM, Samuel Kleinmeta...@gmail.com wrote: Journal needs to cover these features (whatever they resolve to be). Every activity author should not be inventing various implementations of a book shelf UI concepts for dealing with a monoculture 'collection' of objects. Imagine if I wanted to put together a 'collection' of Physics simulations to teach curriculum, or some Turtle Art projects teaching the idea of vectors, or a mix of both along with a book or two and a Labyrinth mind-map of topic notes. What happens if an Activity wants to use the ObjectChooser to pick an object buried in someone else's collection. On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: I do agree with you that it is the Journal which should be doing this, and not Read (except for maybe accessing online catalogs - though I think James has a better approach with his Get IA Books activity. It's just that, I'm a bit frustrated with the current state of the journal (especially for handling collections), and while xol-s are a great idea in theory, the practice of jumping through the browser (especially if Rainbow is enabled) is extremely crappy, IMHO :-). However, after going through all the mails, especially the links which Aleksey sent, I think it may be worthwhile to devote my coding cycles to the Journal instead. I disagree here. In theory, it is nice to imagine you might only need to solve a large # of similar interface and design problems once for every situation. In practice, it is really difficult to design a smooth, fast, rewarding interface for a general problem : a focused use case, and the freedom to make something work brilliantly for that case without having to demonstrate that it is a good design decision for all other parallel use cases, helps get something useful. I would expect to regularly want my bookshelf to be able to browse through hundreds of files at once, searching and autocompleting through their specific index; sort by book-specific metadata fields; and handle a collection 90% of which I am not storing locally -- possibly requesting a book from a repository off-disk, possibly keeping a fixed size on-disk library and having a process for queueing old books for local removal. Yes, an Ideal Journal might include these features. But I expect a Read -- Get IA Books activity might deal with this over the next year or two much more effectively than an a Journal being pulled in many directions. I do agree with you that the Journal should not take care of business like searching through external repositories, in fact, IMHO, the Journal should not do anything that makes it try to connect to the Internet, or even a school server (a hard dependency on network should be avoided as much as possible). However, given that, I think, mimetype specific custom metadata support in Journal should give us a reasonable way to manage books stored locally - and if no one else is working on it right now, I can take a shot. What I do not want to do at this stage is do the book management inside Read itself (it is Read, and not Manage Books :-). A separate activity is required for retrieving books from external sources, and I think Get IA Books is a great start, and can be quickly extended to support something like Feedbooks (though probably we need to consider Feedbook's ToS at http://www.feedbooks.com/termsofuse before trying to go ahead with the coding). We may even want to support OPDS catalogs (compressed as well as uncompressed) as journal objects, opened and browsable via Get IA Books or its later form. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Sat, Aug 1, 2009 at 04:17, Samuel Kleinmeta...@gmail.com wrote: Journal needs to cover these features (whatever they resolve to be). Every activity author should not be inventing various implementations of a book shelf UI concepts for dealing with a monoculture 'collection' of objects. Imagine if I wanted to put together a 'collection' of Physics simulations to teach curriculum, or some Turtle Art projects teaching the idea of vectors, or a mix of both along with a book or two and a Labyrinth mind-map of topic notes. What happens if an Activity wants to use the ObjectChooser to pick an object buried in someone else's collection. On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: I do agree with you that it is the Journal which should be doing this, and not Read (except for maybe accessing online catalogs - though I think James has a better approach with his Get IA Books activity. It's just that, I'm a bit frustrated with the current state of the journal (especially for handling collections), and while xol-s are a great idea in theory, the practice of jumping through the browser (especially if Rainbow is enabled) is extremely crappy, IMHO :-). However, after going through all the mails, especially the links which Aleksey sent, I think it may be worthwhile to devote my coding cycles to the Journal instead. I disagree here. In theory, it is nice to imagine you might only need to solve a large # of similar interface and design problems once for every situation. In practice, it is really difficult to design a smooth, fast, rewarding interface for a general problem : a focused use case, and the freedom to make something work brilliantly for that case without having to demonstrate that it is a good design decision for all other parallel use cases, helps get something useful. I would expect to regularly want my bookshelf to be able to browse through hundreds of files at once, searching and autocompleting through their specific index; sort by book-specific metadata fields; and handle a collection 90% of which I am not storing locally -- possibly requesting a book from a repository off-disk, possibly keeping a fixed size on-disk library and having a process for queueing old books for local removal. Yes, an Ideal Journal might include these features. But I expect a Read -- Get IA Books activity might deal with this over the next year or two much more effectively than an a Journal being pulled in many directions. I don't see much value right now in speculating whether those features will come first from the journal or from activities. I agree that it'd be best if they appeared in the journal, and also agree it's better that they appear first in activities rather than not having them at all. But it all will depend at the end on who is willing to do the work and at which level. Doing so in activities makes it less complicated for the lone coder because can just code it, upload the bundle to ASLO and announce it. Doing it in the journal will benefit more use cases, but agreement with the rest of the community is needed before it can be released. Regards, Tomeu S. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Journal needs to cover these features (whatever they resolve to be). Every activity author should not be inventing various implementations of a book shelf UI concepts for dealing with a monoculture 'collection' of objects. Imagine if I wanted to put together a 'collection' of Physics simulations to teach curriculum, or some Turtle Art projects teaching the idea of vectors, or a mix of both along with a book or two and a Labyrinth mind-map of topic notes. What happens if an Activity wants to use the ObjectChooser to pick an object buried in someone else's collection. On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta sayami...@gmail.comwrote: I do agree with you that it is the Journal which should be doing this, and not Read (except for maybe accessing online catalogs - though I think James has a better approach with his Get IA Books activity. It's just that, I'm a bit frustrated with the current state of the journal (especially for handling collections), and while xol-s are a great idea in theory, the practice of jumping through the browser (especially if Rainbow is enabled) is extremely crappy, IMHO :-). However, after going through all the mails, especially the links which Aleksey sent, I think it may be worthwhile to devote my coding cycles to the Journal instead. I disagree here. In theory, it is nice to imagine you might only need to solve a large # of similar interface and design problems once for every situation. In practice, it is really difficult to design a smooth, fast, rewarding interface for a general problem : a focused use case, and the freedom to make something work brilliantly for that case without having to demonstrate that it is a good design decision for all other parallel use cases, helps get something useful. I would expect to regularly want my bookshelf to be able to browse through hundreds of files at once, searching and autocompleting through their specific index; sort by book-specific metadata fields; and handle a collection 90% of which I am not storing locally -- possibly requesting a book from a repository off-disk, possibly keeping a fixed size on-disk library and having a process for queueing old books for local removal. Yes, an Ideal Journal might include these features. But I expect a Read -- Get IA Books activity might deal with this over the next year or two much more effectively than an a Journal being pulled in many directions. S. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Hi Aleksey, On 25 Jul 2009, at 17:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:24:33PM +0100, Gary C Martin wrote: Hi Aleksey, On 25 Jul 2009, at 05:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote: The term content bundles is still pretty wooly for me. Are we talking zip files, perhaps with some formal structure? Object Bundles[1] will deprecate .xol in 0.86 and in case of previews, it will be regular field in METADATA file: preview_file = file-inside-bundle-with-preview [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file Thanks for the references. Having read that page I'm still confused about aspects of this proposal. Not sure I'm clear enough to ask sane questions. Let me try: 1) By composite object do you mean a container of many files/folders (a little like current .xol), or a container of many Journal compatible entries (i.e. 40 Read Activity pdf ebooks with thumbnail images, tags, and description)? Container of of many files/folders that represented by one Journal entry so, in case of library it would be: one entry in Journal which has text/html and directory with content of library(somewhere). After activating it, Browse will open one of many files/folders e.g. index.html 2) Is .xol extension proposed to go away, or will .xol be repurposed as a the composite object? In case of [1] .xol is just a subset of object bundles and sugar will still support former .xol(but they will be deprecated) 3) Why should a composite object open in Browse, is this just an example of a zipped up web site? Because Journal entry which represent composite object will have text/html mime_type, in face there is only one difference between regular Journal objects and composite - regular object has only one file but composite has directory. +1 Thanks, understood. 4) Will .xo will be used to store Activity bundles (i.e as we have now), and Activity entries (i.e. all meta-data and files as found for a Journal entry)? Activity just another example of composite object(in common sense) and I'm thinking about adding them to 0.86 as well. According to [2] there could be two forms of object bundles: * one or several packed Activity entries (they can have activity field) * the while bundle as composite object which will be represented by one Journal activity-less object (e.g. library or activity) OK, I think I understand that :-) 1) 1 (to N) Activity entries, all wrapped inside the .xo, on download to Journal they are all expanded as individual Journal entries. +1 :-) 2) A zipped folder of files/folders that is placed in the Journal as a single entry (composite object). Question: Is this equivalent to an .xol? Or, can it hold arbitrary files (i.e .xol is a subset), like a bunch of C source files? Maybe you want to make a Gcc Activity to open this composite object at some point? ;-b 5) Meta-data kept in an INI rather than json a file? In INI format since its easier for hand-editing What about non- text meta-data, the preview image comes to mind, but an activity might be storing other non text blobs of meta-data. Any field in METADATA file can have _file suffix, in that case content of this field(substring w/o _file suffix) will be fetched from file inside of the bundle e.g. preview_file=filename-from-bundle to fill preview field. Thanks, sorry I missed the relevance of that when reading your wiki spec. Understood now. These would be some pretty useful/powerful additions! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Sun, Jul 26, 2009 at 04:56:40PM +0100, Gary C Martin wrote: Hi Aleksey, On 25 Jul 2009, at 17:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:24:33PM +0100, Gary C Martin wrote: Hi Aleksey, On 25 Jul 2009, at 05:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote: The term content bundles is still pretty wooly for me. Are we talking zip files, perhaps with some formal structure? Object Bundles[1] will deprecate .xol in 0.86 and in case of previews, it will be regular field in METADATA file: preview_file = file-inside-bundle-with-preview [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file Thanks for the references. Having read that page I'm still confused about aspects of this proposal. Not sure I'm clear enough to ask sane questions. Let me try: 1) By composite object do you mean a container of many files/folders (a little like current .xol), or a container of many Journal compatible entries (i.e. 40 Read Activity pdf ebooks with thumbnail images, tags, and description)? Container of of many files/folders that represented by one Journal entry so, in case of library it would be: one entry in Journal which has text/html and directory with content of library(somewhere). After activating it, Browse will open one of many files/folders e.g. index.html 2) Is .xol extension proposed to go away, or will .xol be repurposed as a the composite object? In case of [1] .xol is just a subset of object bundles and sugar will still support former .xol(but they will be deprecated) 3) Why should a composite object open in Browse, is this just an example of a zipped up web site? Because Journal entry which represent composite object will have text/html mime_type, in face there is only one difference between regular Journal objects and composite - regular object has only one file but composite has directory. +1 Thanks, understood. 4) Will .xo will be used to store Activity bundles (i.e as we have now), and Activity entries (i.e. all meta-data and files as found for a Journal entry)? Activity just another example of composite object(in common sense) and I'm thinking about adding them to 0.86 as well. According to [2] there could be two forms of object bundles: * one or several packed Activity entries (they can have activity field) * the while bundle as composite object which will be represented by one Journal activity-less object (e.g. library or activity) OK, I think I understand that :-) 1) 1 (to N) Activity entries, all wrapped inside the .xo, on download to Journal they are all expanded as individual Journal entries. +1 :-) 2) A zipped folder of files/folders that is placed in the Journal as a single entry (composite object). Question: Is this equivalent to an .xol? Or, can it hold arbitrary files (i.e .xol is a subset), yup, arbitrary files library bundle is just a good example btw another good example is activity bundles but adding activity bundles requires more coding except just adding them to OB. Anyway I think its really doable in 0.86 cycle like a bunch of C source files? Maybe you want to make a Gcc Activity to open this composite object at some point? ;-b 5) Meta-data kept in an INI rather than json a file? In INI format since its easier for hand-editing What about non- text meta-data, the preview image comes to mind, but an activity might be storing other non text blobs of meta-data. Any field in METADATA file can have _file suffix, in that case content of this field(substring w/o _file suffix) will be fetched from file inside of the bundle e.g. preview_file=filename-from-bundle to fill preview field. Thanks, sorry I missed the relevance of that when reading your wiki spec. Understood now. These would be some pretty useful/powerful additions! Regards, --Gary -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Sun, Jul 26, 2009 at 11:56 AM, Gary C Marting...@garycmartin.com wrote: Hi Aleksey, On 25 Jul 2009, at 17:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:24:33PM +0100, Gary C Martin wrote: Hi Aleksey, On 25 Jul 2009, at 05:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote: The term content bundles is still pretty wooly for me. Are we talking zip files, perhaps with some formal structure? Object Bundles[1] will deprecate .xol in 0.86 and in case of previews, it will be regular field in METADATA file: preview_file = file-inside-bundle-with-preview [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file Thanks for the references. Having read that page I'm still confused about aspects of this proposal. Not sure I'm clear enough to ask sane questions. Let me try: 1) By composite object do you mean a container of many files/folders (a little like current .xol), or a container of many Journal compatible entries (i.e. 40 Read Activity pdf ebooks with thumbnail images, tags, and description)? Container of of many files/folders that represented by one Journal entry so, in case of library it would be: one entry in Journal which has text/html and directory with content of library(somewhere). After activating it, Browse will open one of many files/folders e.g. index.html 2) Is .xol extension proposed to go away, or will .xol be repurposed as a the composite object? In case of [1] .xol is just a subset of object bundles and sugar will still support former .xol(but they will be deprecated) 3) Why should a composite object open in Browse, is this just an example of a zipped up web site? Because Journal entry which represent composite object will have text/html mime_type, in face there is only one difference between regular Journal objects and composite - regular object has only one file but composite has directory. +1 Thanks, understood. 4) Will .xo will be used to store Activity bundles (i.e as we have now), and Activity entries (i.e. all meta-data and files as found for a Journal entry)? Activity just another example of composite object(in common sense) and I'm thinking about adding them to 0.86 as well. According to [2] there could be two forms of object bundles: * one or several packed Activity entries (they can have activity field) * the while bundle as composite object which will be represented by one Journal activity-less object (e.g. library or activity) OK, I think I understand that :-) 1) 1 (to N) Activity entries, all wrapped inside the .xo, on download to Journal they are all expanded as individual Journal entries. +1 :-) 2) A zipped folder of files/folders that is placed in the Journal as a single entry (composite object). Question: Is this equivalent to an .xol? Or, can it hold arbitrary files (i.e .xol is a subset), like a bunch of C source files? Maybe you want to make a Gcc Activity to open this composite object at some point? ;-b I've always envisioned a Bundle activity which is a glorified tar/zip/other-bundle-format viewing and creation tool. With Bundle, it would be possible to open any such file in the Journal (including activity bundles, of course) to view its contents. It would also support extracting all or part of the bundle contents to separate Journal entries, as well as creating new bundles from arbitrary collections of objects. It would even be possible to add collaboration on top of this, so groups of kids could create bundles together, aggregating entries from each of their Journals into a single product. This would be useful for group projects, for instance. I know a class took this on as a project at one point, though I never heard how that turned out. I believe this—http://activities.sugarlabs.org/en-US/sugar/addon/4079—is the result, but I haven't had a chance to try it yet. In any case, it might be nice to keep it in mind, and perhaps extend its features in line with these new discussions for object bundles if appropriate. For instance, it might be possible to add some GUI tools for viewing/populating Sugar-specific manifest files, when desired. As a side note, I have an icon for Bundle which we've had around since the early design stages of Sugar, and the icon shown there isn't HIG compliant. Jake, would you be willing to update the bundle with a new icon if I supplied you with one? Eben 5) Meta-data kept in an INI rather than json a file? In INI format since its easier for hand-editing What about non- text meta-data, the preview image comes to mind, but an activity might be storing other non text blobs of meta-data. Any field in METADATA file can have _file suffix, in that case content of this field(substring w/o _file suffix) will be fetched from file inside of the bundle e.g. preview_file=filename-from-bundle to fill preview field. Thanks, sorry I missed the relevance of
Re: [Sugar-devel] Book bundles and Read
On 26 Jul 2009, at 20:16, Eben Eliason wrote: I've always envisioned a Bundle activity which is a glorified tar/zip/other-bundle-format viewing and creation tool. With Bundle, it would be possible to open any such file in the Journal (including activity bundles, of course) to view its contents. It would also support extracting all or part of the bundle contents to separate Journal entries, as well as creating new bundles from arbitrary collections of objects. It would even be possible to add collaboration on top of this, so groups of kids could create bundles together, aggregating entries from each of their Journals into a single product. This would be useful for group projects, for instance. I know a class took this on as a project at one point, though I never heard how that turned out. I believe this—http://activities.sugarlabs.org/en-US/sugar/addon/4079—is the result, but I haven't had a chance to try it yet. In any case, it might be nice to keep it in mind, and perhaps extend its features in line with these new discussions for object bundles if appropriate. For instance, it might be possible to add some GUI tools for viewing/populating Sugar-specific manifest files, when desired. Ah! thanks Eben, it had slipped under my radar (had been looking for it on out Gitorious site). I'll give the Activity a test and see what's what. Regards --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
All, In my own emails when I refer to content bundles I am not referring to anything that Sugar Labs has proposed as a standard. I was just thinking about how to deal with the Children's Book Library project, how would I deal with the problem of distributing 2,000 books to children without access to the Internet or even a local web server, knowing the limitations of the Journal Activity as it exists in .82. I came up with the idea of: 1). PDF books stored in zip files along with gif files representing their book covers plus a catalog file. 2). An Activity, possibly an enhancement to Get Internet Archive Books that would browse this catalog file and create a user interface allowing the books to be browsed and copied to the Journal one at a time. I suggested that the catalog file be in Dublin Core format because that seems to be trendy but truthfully I'd be happy with a catalog of delimited lines like this: The Innocents Abroad|Mark Twain (Samuel Clemens)|Travel, Humor|innocents where innocents.pdf is the name of the PDF and innocents.gif is the cover page image. I've been a professional programmer for over thirty years so my method tends to be: 1). What do we have? 2). What do we want to do with it? 3). What is the simplest (not necessarily the most generally useful) way to get there? I certainly can understand the value of a good standard approach to this kind of problem but I wasn't trying to propose one. James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
A possible solution for 2. The catalog file should be a .html file with file:// links to the USB drive. If the kid opens the .html file in Browse and clicks on the link then it will be copied to the Journal and opened in Read. The .html file can have pictures. The only criterium is that the links shall point to /media/BOOKS/bah.pdf where the USB drive's label is fixed. Jim Simmons wrote: All, In my own emails when I refer to content bundles I am not referring to anything that Sugar Labs has proposed as a standard. I was just thinking about how to deal with the Children's Book Library project, how would I deal with the problem of distributing 2,000 books to children without access to the Internet or even a local web server, knowing the limitations of the Journal Activity as it exists in .82. I came up with the idea of: 1). PDF books stored in zip files along with gif files representing their book covers plus a catalog file. 2). An Activity, possibly an enhancement to Get Internet Archive Books that would browse this catalog file and create a user interface allowing the books to be browsed and copied to the Journal one at a time. I suggested that the catalog file be in Dublin Core format because that seems to be trendy but truthfully I'd be happy with a catalog of delimited lines like this: The Innocents Abroad|Mark Twain (Samuel Clemens)|Travel, Humor|innocents where innocents.pdf is the name of the PDF and innocents.gif is the cover page image. I've been a professional programmer for over thirty years so my method tends to be: 1). What do we have? 2). What do we want to do with it? 3). What is the simplest (not necessarily the most generally useful) way to get there? I certainly can understand the value of a good standard approach to this kind of problem but I wasn't trying to propose one. James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Gary, I was thinking myself that enhancing Get Internet Archive Books to deal with local zip files of books as well as the Internet would be a possible approach. Currently GIAB produces and can be resumed from a Journal entry but does nothing with it. I might change that so it can be resumed from a file of MIME type application/zip. If it is resumed from that it would check the Zip file for the catalog XML file and build a user interface using that. Maybe there would be a toolbar tab named USB for this interface. Resuming from a thumb drive does not present any security problems, and I'd only read it, not write to it. James Simmons On Thu, Jul 23, 2009 at 5:48 PM, Gary C Marting...@garycmartin.com wrote: On 23 Jul 2009, at 18:28, Gary C Martin wrote: Just wondering. If I had a USB stick with 2,000 pdf, plain text, etext, djvu, epub etc files on it... if they are at least reasonably well titled file names (lets say at least title, author), then a child can: 1). pop in the USB stick 2). goto the Journal and select the external USB stick icon 3). search and/or browse the books by author / title 4). any entry they want can be dragged to their Journal icon 5). ...or clicking any object entry will both start it for reading and copy it into the childs Journal Just to be clear, this is the behaviour since the data-store (and Journal?) re-work from Tomeu. I just ran the same test on an 0.82.1 release and had some different results: - I could rename, add tags, favourite and add descriptions; but this would appear as a duplicate entry on the stick next time I mounted the device. It would fail to start, but the old unchanged version would still be listed and would still work. Seem to remember this as an old indexing bug and part of the reason for the need to re-work the data-store to be robust. - resuming a pdf from the stick would view it in Read correctly but not copy the file over to the local data-store. When closing Read, it would then display a keep error (likely as the old data-store couldn't deal correctly with writing to external media). So, if you're looking to support deployments unwilling or unable to upgrade Sugar (likely a very large slice I'd imagine). This looks like you will need to bake your own Activity solution :-( Random thoughts. Both old and new external media support allows for starting an .xo Activity bundle. The Activity is installed and started. So you could extend the Get IA Books Activity to have a thumbnail view and have it check an external media device for a local archive format of some kind. Then just distribute a USB stick with the .xo bundle and the local archive of book content. Get IA Books Activity could then be launched, if found would default to the local archive, then any chosen books would be saved to the Journal. Both old and new external media also support for hiding files with the leading . (dot) character, so you could potentially hide the archive structure from the Journal view to prevent kids from clicking on it, just showing them the Get IA Books Activity icon. One unknown spanner in the works to test for, is what access restrictions an Activity might hit trying to arbitrarily read from an external media device, haven't had to do this myself. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Hi James, On 24 Jul 2009, at 15:21, Jim Simmons wrote: Gary, I was thinking myself that enhancing Get Internet Archive Books to deal with local zip files of books as well as the Internet would be a possible approach. Currently GIAB produces and can be resumed from a Journal entry but does nothing with it. I might change that so it can be resumed from a file of MIME type application/zip. If it is resumed from that it would check the Zip file for the catalog XML file and build a user interface using that. You might want to consider having the .zip file with a different extension (like we have .xo and .xol, or mozilla's .jar). That way you can have GIAB be the default rather than needing to use 'resume with - ' in current Sugar (in 0.82.x Sugar you have to dig into the Journal details view toolbar). OT: There was a University project working on a Bundle activity but it seems to have died a death, maybe I should try and pick this one up. We could really do with a clean/simple Bundle Activity that would deal with any regular .zip (perhaps some other archive formats too) and allow items to be selected extracted to the Journal, and the reverse operation where you can pick objects from the Journal (using ObjectChooser) for bundling together into a zip (or other format). This is really just a Sugar friendly gui for zip/unzip. Maybe there would be a toolbar tab named USB for this interface. How about another drop down menu next to the one you currently use for selecting Deja Vu, pdf download formats? It could also allow for other resource locations you may decide to add in the future Internet Archive, Project Guttenberg, USB, Schoolserver. Resuming from a thumb drive does not present any security problems, and I'd only read it, not write to it. Might just want to check you are not sandboxed in by Rainbow from reading as well (I can't remember). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Fri, Jul 24, 2009 at 2:14 AM, Gary C Marting...@garycmartin.com wrote: Hi Sayamindu, On 23 Jul 2009, at 19:02, Sayamindu Dasgupta wrote: On Thu, Jul 23, 2009 at 9:03 AM, Gary C Marting...@garycmartin.com wrote: ..snip snip Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I think Read can be able to handle that. It means some extra work in the code, but it can be possible to extend the metadata in such a way that the state for each and every book in the bundle/collection is remembered. Of course you can hack on Read and make it handle all this bundle/collection stuff :-) but my argument is Read should not really be doing this extra step. Journal needs to cover these features (whatever they resolve to be). Every activity author should not be inventing various implementations of a book shelf UI concepts for dealing with a monoculture 'collection' of objects. Imagine if I wanted to put together a 'collection' of Physics simulations to teach curriculum, or some Turtle Art projects teaching the idea of vectors, or a mix of both along with a book or two and a Labyrinth mind-map of topic notes. What happens if an Activity wants to use the ObjectChooser to pick an object buried in someone else's collection. A combination of a Journal grid view and correctly tagging objects would pretty much solve the UI side; with perhaps a bundle format (maybe repurpose .xol) so that downloading one auto extracted to a number of tagged Journal entries; and the reverse perhaps being true where you select N existing Journal entries and send to - ... causes them to be zipped up as a .xol and transferred as a single item. I do agree with you that it is the Journal which should be doing this, and not Read (except for maybe accessing online catalogs - though I think James has a better approach with his Get IA Books activity. It's just that, I'm a bit frustrated with the current state of the journal (especially for handling collections), and while xol-s are a great idea in theory, the practice of jumping through the browser (especially if Rainbow is enabled) is extremely crappy, IMHO :-). However, after going through all the mails, especially the links which Aleksey sent, I think it may be worthwhile to devote my coding cycles to the Journal instead. James' existing working solutions, Read EText, and Get Internet Archive Books (which BTW already downloads nice PDFs for Read to read), focus on using existing online resources for downloading new content to the Journal. This seems like a good Sugar Activity design pattern for cases where large online monocultures of resources already exist. Are you looking to fold his work into Read**? I have plans on working on James's activity (I would probably try to not restrict the activity to the Internet Archive), and I'm waiting for the OPDS standard to mature a bit more before looking seriously into online content aggregation. **I would have been great if Read had been extended, rather than a separate Read EText Activity created, but I guess that's water under the bridge now. I agree - however, there is a large amount of code sharing that goes between the two projects, and I'm in the middle of adding a extra layer between Read's view widget and Evince, so that at some point, Read would be able to handle Etexts as well, reusing James's code. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Thu, Jul 23, 2009 at 5:09 PM, Gary C Marting...@garycmartin.com wrote: On 23 Jul 2009, at 21:36, Jim Simmons wrote: Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. Yes, book cover images, is the big missing feature with current Journal abilities when accessing external media (along with a Journal thumb view, but hopefully that feature is coming). We should provide a way to populate the previews for the entries within content bundles. With this, and a grid view, we'd be in good shape. The problem I have with USB devices on the Journal is that they are listed in descending order by the date and time they were created. Even a few hundred books on a USB stick isn't all that easy to manage. (I have an SD drive with 2 GB worth of comic books and it really bugs me that they aren't in alphabetical order). Searching is fine if you know what you're The Journal is spec'd to have sorting capability, and Tomeu has done some work toward this end. It should be possible to sort by date, title, type, and participants. looking for. In this case the kid might be asked by his teacher to pick out a book from the conduct of life collection and do a report on it. The teacher asking students to pick out a book from the 'conduct of life' is the easy case :-) The kid just types 'conduct of life' into the Journal search filed, and just those books are listed. All that the USB stick would have needed is for those books to be in a directory called conduct of life, or for that text to be part of each books file name title. Like any real bricks and mortar library, putting the books in some sort of order, up front, really helps the punters in finding what they are looking for ;-) In that case the kid really needs to be able to search the USB drive as if it was a real bookshelf, look at the book covers, read descriptions, etc. What I had proposed would allow that. Yes, Journal type meta-data is not supported on external media unfortunately (though that is a really tough problem to solve). I guess you can make the argument for creating custom file layouts / index that you implement in Journal (E), so that you can stick book thumbs and metadata in known names/folders... But this is just a Oh. That's what I was suggesting above. I guess you're right. It would be very useful, though... re-implementation of the data-store format from Tomeu, so no need to re-invent or re-implement, just use the existing format for free! What this would mean for the Journal is allowing external volumes/ media to be flagged in some way so that the Journal would read and display their data just like from the local Sugar data-store. I guess this could be very low hanging fruit, you'd need to ask Tomeu... The We have discussed the idea of offering an Extend my Journal option for external media. It would be particularly useful for SD cards which can be more or less permanently installed. I think it's an intriguing idea. flag could be something as simple as an empty root level file on the volume named to indicate the volume is in data-store format and should be treated as such. The idea is to provide books to kids that don't have access to the Internet, either because it isn't available or because of parental concern. +1 Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Hi Eben, On 25 Jul 2009, at 02:24, Eben Eliason wrote: On Thu, Jul 23, 2009 at 5:09 PM, Gary C Marting...@garycmartin.com wrote: On 23 Jul 2009, at 21:36, Jim Simmons wrote: Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. Yes, book cover images, is the big missing feature with current Journal abilities when accessing external media (along with a Journal thumb view, but hopefully that feature is coming). We should provide a way to populate the previews for the entries within content bundles. With this, and a grid view, we'd be in good shape. The term content bundles is still pretty wooly for me. Are we talking zip files, perhaps with some formal structure? The problem I have with USB devices on the Journal is that they are listed in descending order by the date and time they were created. Even a few hundred books on a USB stick isn't all that easy to manage. (I have an SD drive with 2 GB worth of comic books and it really bugs me that they aren't in alphabetical order). Searching is fine if you know what you're The Journal is spec'd to have sorting capability, and Tomeu has done some work toward this end. It should be possible to sort by date, title, type, and participants. H, yea... I'm so close to filing this as blocker BUG on 0.85.x to be honest :-) It eats screen space, complicates the UI, drops all kinds of unexpected new view 'modes' on the user, and is close to useless unless you're an obsessive compulsive disorder type with an unhealthy addiction to titling everything with alphabetical sorting in mind. For the columns we have, it's about as useful an improvement for me as tying a sack over my head and pushing me in a swimming pool. Try it (0.85.x, not the swimming pool thing)! Apart from tag filters (which already work great, but just needs to be more accessible/visible), sort by creation data seems to be the big Journal omission. This would be covered by your proposed action-view (which is inherently a creation ordered log of actions, as I understand). Right now you can't tell what you did last week because everything is sorted by modification date – if you so much as look at an entry, it jumps out of order to the top of the Journal. looking for. In this case the kid might be asked by his teacher to pick out a book from the conduct of life collection and do a report on it. The teacher asking students to pick out a book from the 'conduct of life' is the easy case :-) The kid just types 'conduct of life' into the Journal search filed, and just those books are listed. All that the USB stick would have needed is for those books to be in a directory called conduct of life, or for that text to be part of each books file name title. Like any real bricks and mortar library, putting the books in some sort of order, up front, really helps the punters in finding what they are looking for ;-) In that case the kid really needs to be able to search the USB drive as if it was a real bookshelf, look at the book covers, read descriptions, etc. What I had proposed would allow that. Yes, Journal type meta-data is not supported on external media unfortunately (though that is a really tough problem to solve). I guess you can make the argument for creating custom file layouts / index that you implement in Journal (E), so that you can stick book thumbs and metadata in known names/folders... But this is just a Oh. That's what I was suggesting above. I guess you're right. It would be very useful, though... re-implementation of the data-store format from Tomeu, so no need to re-invent or re-implement, just use the existing format for free! What this would mean for the Journal is allowing external volumes/ media to be flagged in some way so that the Journal would read and display their data just like from the local Sugar data-store. I guess this could be very low hanging fruit, you'd need to ask Tomeu... The We have discussed the idea of offering an Extend my Journal option for external media. It would be particularly useful for SD cards which can be more or less permanently installed. I think it's an intriguing idea. I wasn't going for the Extend my Journal case here. That would indicate database/indexes that span multiple volumes and dealing with potentially missing volumes, and likely some smooth process as you fill up one volume to move over to using the next, etc. Sounds pretty complicated. I was just suggesting that you could flag a media volume in some way so that Journal would treat it as a full fat, meta-data journal entries, using the data-store format. It's great that the current default view of external media is cross-platform friendly, but it would be useful to be able to provide rich (Journal) content for USB/ SD distribution (fully tagged, titled, described, and with thumbnail previews). flag could be
Re: [Sugar-devel] Book bundles and Read
On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote: Hi Eben, On 25 Jul 2009, at 02:24, Eben Eliason wrote: On Thu, Jul 23, 2009 at 5:09 PM, Gary C Marting...@garycmartin.com wrote: On 23 Jul 2009, at 21:36, Jim Simmons wrote: Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. Yes, book cover images, is the big missing feature with current Journal abilities when accessing external media (along with a Journal thumb view, but hopefully that feature is coming). We should provide a way to populate the previews for the entries within content bundles. With this, and a grid view, we'd be in good shape. The term content bundles is still pretty wooly for me. Are we talking zip files, perhaps with some formal structure? Object Bundles[1] will deprecate .xol in 0.86 and in case of previews, it will be regular field in METADATA file: preview_file = file-inside-bundle-with-preview [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Yesterday I had an email exchange with Scotty Auble of the Rural Design Collective project who have a list of 2,000 some odd books they want to distribute to Sugar users without requiring them to have Internet access. The thought I had was Zip archives with a catalog file, perhaps in Dublin Core format, and a new Activity that would look inside these archives, generate a browsable catalog from the catalog file, and allow the child to select the books he likes and create Journal entries for them. I copied this email to the IAEP list but not here. I agree with the points Gary is making below and wonder if we need a different kind of bundle that can be used to distribute collections of books without requiring the child to install the whole collection. James Simmons Date: Thu, 23 Jul 2009 04:33:09 +0100 From: Gary C Martin g...@garycmartin.com Subject: Re: [Sugar-devel] Book bundles and Read To: Sayamindu Dasgupta sayami...@gmail.com Cc: Sugar devel sugar-devel@lists.sugarlabs.org, OLPC Bookreader list bookrea...@lists.laptop.org Message-ID: 37e66200-fa85-4d24-aa3e-9e2a3a520...@garycmartin.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I'd be quite happy with zipped bundles that expanded into objects in the Journal, well tagged, nicely titled, and with thumbnails. That's where the big win is in my mind for distributing content. The xol was a reasonable idea, but narrow thinking, it missed the whole point of Sugar being centred around a core Journal where entries can make use of all the search, tagging, and preview features it offers for free. If the Journal managed to pick up a thumb/grid view in the 0.86 cycle, courtesy of Aleksey, then that view plus tagging (author, genre, et al) will make Journal your searchable book shelf, when you need it to be, and Read (or any other Activity) can focus on presenting great content well :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Hi James, On 23 Jul 2009, at 16:52, Jim Simmons wrote: Yesterday I had an email exchange with Scotty Auble of the Rural Design Collective project who have a list of 2,000 some odd books they want to distribute to Sugar users without requiring them to have Internet access. The thought I had was Zip archives with a catalog file, perhaps in Dublin Core format, and a new Activity that would look inside these archives, generate a browsable catalog from the catalog file, and allow the child to select the books he likes and create Journal entries for them. I copied this email to the IAEP list but not here. I agree with the points Gary is making below and wonder if we need a different kind of bundle that can be used to distribute collections of books without requiring the child to install the whole collection. Just wondering. If I had a USB stick with 2,000 pdf, plain text, etext, djvu, epub etc files on it... if they are at least reasonably well titled file names (lets say at least title, author), then a child can: 1). pop in the USB stick 2). goto the Journal and select the external USB stick icon 3). search and/or browse the books by author / title 4). any entry they want can be dragged to their Journal icon 5). ...or clicking any object entry will both start it for reading and copy it into the childs Journal FWIW some find step 5 a limitation or design bug for Sugar, in that you can't work with files on external media that are larger than the free space you have left in your Journal. Step 4 could be better, as the icon for your Journal (appears in a bottom tray when additional media devices are present), is actually an XO kid icon, would be more logical to show the Journal icon I think. Step 3 clearly could be prettier but would require some way of generating live previews for the entries currently in view (and then you could use the proposed Journal grid view to view book covers). It's also worth noting that although directory structure of the external media is not displayed directly (Journal shows a flattened list of all files), the full directory path to the file is placed in its description field. This is all fully searchable data, so you could put all the Lewis Carroll books in a folder of that name, and that would be enough to allow you to query Journal for them. So just some well chosen directory names (by author seems sensible), and consistently well named files (i.e full title of book) would make quite an accessible solution. Perhaps if there's interest, we can polish some of the above steps to make it even smoother in 0.86? Regards, --Gary Date: Thu, 23 Jul 2009 04:33:09 +0100 From: Gary C Martin g...@garycmartin.com Subject: Re: [Sugar-devel] Book bundles and Read To: Sayamindu Dasgupta sayami...@gmail.com Cc: Sugar devel sugar-devel@lists.sugarlabs.org, OLPC Bookreader list bookrea...@lists.laptop.org Message-ID: 37e66200-fa85-4d24-aa3e-9e2a3a520...@garycmartin.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I'd be quite happy with zipped bundles that expanded into objects in the Journal, well tagged, nicely titled, and with thumbnails. That's where the big win is in my mind for distributing content. The xol was a reasonable idea, but narrow thinking, it missed the whole point of Sugar being centred around a core Journal where entries can make use of all the search, tagging, and preview features it offers for free. If the Journal managed to pick up a thumb/grid view in the 0.86 cycle, courtesy of Aleksey, then that view plus tagging (author, genre, et al) will make Journal your searchable book shelf, when you need it to be, and Read (or any other Activity) can focus on presenting great content well :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Missing here is a way to handily install/uninstall a named set of works from your journal/XO. If you could search through the 2000 books on a usb stick, find 40 results, copy those into your Journal as a named collection, and later choose to read individual books (without making na addition on-disk copy) or uninstall that collection (without individually uninstalling all 40 books), that would be a good user experience. The journal entry for reading a book from a collection could be a metadata entry with all the informatino about the book, but could point to the existing collection (at appropriate index even) for the work itself. The catalog file with the data about all 40 books should be searchable through the journal as well for every bundle, which would allow you to pull up the collection when searching for one of its elements. then you'd need an additional info-rich detailed view for a collection within the journal (which is needed anyway -- bundles are much more complex than a single text file or image). SJ On Thu, Jul 23, 2009 at 1:28 PM, Gary C Martin g...@garycmartin.com wrote: Hi James, On 23 Jul 2009, at 16:52, Jim Simmons wrote: Yesterday I had an email exchange with Scotty Auble of the Rural Design Collective project who have a list of 2,000 some odd books they want to distribute to Sugar users without requiring them to have Internet access. The thought I had was Zip archives with a catalog file, perhaps in Dublin Core format, and a new Activity that would look inside these archives, generate a browsable catalog from the catalog file, and allow the child to select the books he likes and create Journal entries for them. I copied this email to the IAEP list but not here. I agree with the points Gary is making below and wonder if we need a different kind of bundle that can be used to distribute collections of books without requiring the child to install the whole collection. Just wondering. If I had a USB stick with 2,000 pdf, plain text, etext, djvu, epub etc files on it... if they are at least reasonably well titled file names (lets say at least title, author), then a child can: 1). pop in the USB stick 2). goto the Journal and select the external USB stick icon 3). search and/or browse the books by author / title 4). any entry they want can be dragged to their Journal icon 5). ...or clicking any object entry will both start it for reading and copy it into the childs Journal FWIW some find step 5 a limitation or design bug for Sugar, in that you can't work with files on external media that are larger than the free space you have left in your Journal. Step 4 could be better, as the icon for your Journal (appears in a bottom tray when additional media devices are present), is actually an XO kid icon, would be more logical to show the Journal icon I think. Step 3 clearly could be prettier but would require some way of generating live previews for the entries currently in view (and then you could use the proposed Journal grid view to view book covers). It's also worth noting that although directory structure of the external media is not displayed directly (Journal shows a flattened list of all files), the full directory path to the file is placed in its description field. This is all fully searchable data, so you could put all the Lewis Carroll books in a folder of that name, and that would be enough to allow you to query Journal for them. So just some well chosen directory names (by author seems sensible), and consistently well named files (i.e full title of book) would make quite an accessible solution. Perhaps if there's interest, we can polish some of the above steps to make it even smoother in 0.86? Regards, --Gary Date: Thu, 23 Jul 2009 04:33:09 +0100 From: Gary C Martin g...@garycmartin.com Subject: Re: [Sugar-devel] Book bundles and Read To: Sayamindu Dasgupta sayami...@gmail.com Cc: Sugar devel sugar-devel@lists.sugarlabs.org, OLPC Bookreader list bookrea...@lists.laptop.org Message-ID: 37e66200-fa85-4d24-aa3e-9e2a3a520...@garycmartin.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I'd be quite happy with zipped bundles that expanded
Re: [Sugar-devel] Book bundles and Read
On Thu, Jul 23, 2009 at 9:03 AM, Gary C Marting...@garycmartin.com wrote: ..snip snip Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I think Read can be able to handle that. It means some extra work in the code, but it can be possible to extend the metadata in such a way that the state for each and every book in the bundle/collection is remembered. I'd be quite happy with zipped bundles that expanded into objects in the Journal, well tagged, nicely titled, and with thumbnails. That's where the big win is in my mind for distributing content. The xol was a reasonable idea, but narrow thinking, it missed the whole point of Sugar being centred around a core Journal where entries can make use of all the search, tagging, and preview features it offers for free. If the Journal managed to pick up a thumb/grid view in the 0.86 cycle, courtesy of Aleksey, then that view plus tagging (author, genre, et al) will make Journal your searchable book shelf, when you need it to be, and Read (or any other Activity) can focus on presenting great content well :-) The book shelf (the catalog view) inside Read needs to be implemented in any case for things like remote catalogs (school server, various on-line distributors, etc). I am a bit unsatisfied with the current .xol based solution, and was wondering if we could leverage the catalog view in Read to handle collections directly. I think it is very important to make sharing of collections easily - and if the Journal is able to do that after expanding the bundle into different objects, I think it will be the most optimal way. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Thu, Jul 23, 2009 at 10:58 PM, Gary C Marting...@garycmartin.com wrote: Hi James, On 23 Jul 2009, at 16:52, Jim Simmons wrote: Yesterday I had an email exchange with Scotty Auble of the Rural Design Collective project who have a list of 2,000 some odd books they want to distribute to Sugar users without requiring them to have Internet access. The thought I had was Zip archives with a catalog file, perhaps in Dublin Core format, and a new Activity that would look inside these archives, generate a browsable catalog from the catalog file, and allow the child to select the books he likes and create Journal entries for them. I copied this email to the IAEP list but not here. I agree with the points Gary is making below and wonder if we need a different kind of bundle that can be used to distribute collections of books without requiring the child to install the whole collection. Just wondering. If I had a USB stick with 2,000 pdf, plain text, etext, djvu, epub etc files on it... if they are at least reasonably well titled file names (lets say at least title, author), then a child can: 1). pop in the USB stick 2). goto the Journal and select the external USB stick icon 3). search and/or browse the books by author / title 4). any entry they want can be dragged to their Journal icon 5). ...or clicking any object entry will both start it for reading and copy it into the childs Journal FWIW some find step 5 a limitation or design bug for Sugar, in that you can't work with files on external media that are larger than the free space you have left in your Journal. Step 4 could be better, as the icon for your Journal (appears in a bottom tray when additional media devices are present), is actually an XO kid icon, would be more logical to show the Journal icon I think. Step 3 clearly could be prettier but would require some way of generating live previews for the entries currently in view (and then you could use the proposed Journal grid view to view book covers). It's also worth noting that although directory structure of the external media is not displayed directly (Journal shows a flattened list of all files), the full directory path to the file is placed in its description field. This is all fully searchable data, so you could put all the Lewis Carroll books in a folder of that name, and that would be enough to allow you to query Journal for them. So just some well chosen directory names (by author seems sensible), and consistently well named files (i.e full title of book) would make quite an accessible solution. Perhaps if there's interest, we can polish some of the above steps to make it even smoother in 0.86? I agree with Gary that a well formed directory structure in a USB key is a nice solution to begin with (though we need to think of better ways to manage collections). However, it would become necessary, at a certain stage to make the Journal aware of metadata files, either as DC XML files, or OPDS catalogs. This is because, the various ebook formats that we currently have differing levels of support for embedding metadata - for example, at one end of the spectrum we have CBZ (Comic Book Archive), which has zero support (AFAIK), and on the other end, we have Epub, which support embedding an entire chunk of Dublin Core metadata elements. For a simple schema like Title/Author, we can use a directory structure, but for example, to support all the 15 elements specified in the simple Dublin Core specs, we would need a quite convoluted directory layout. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. The problem I have with USB devices on the Journal is that they are listed in descending order by the date and time they were created. Even a few hundred books on a USB stick isn't all that easy to manage. (I have an SD drive with 2 GB worth of comic books and it really bugs me that they aren't in alphabetical order). Searching is fine if you know what you're looking for. In this case the kid might be asked by his teacher to pick out a book from the conduct of life collection and do a report on it. In that case the kid really needs to be able to search the USB drive as if it was a real bookshelf, look at the book covers, read descriptions, etc. What I had proposed would allow that. The idea is to provide books to kids that don't have access to the Internet, either because it isn't available or because of parental concern. James Simmons On Thu, Jul 23, 2009 at 12:28 PM, Gary C Marting...@garycmartin.com wrote: Just wondering. If I had a USB stick with 2,000 pdf, plain text, etext, djvu, epub etc files on it... if they are at least reasonably well titled file names (lets say at least title, author), then a child can: 1). pop in the USB stick 2). goto the Journal and select the external USB stick icon 3). search and/or browse the books by author / title 4). any entry they want can be dragged to their Journal icon 5). ...or clicking any object entry will both start it for reading and copy it into the childs Journal FWIW some find step 5 a limitation or design bug for Sugar, in that you can't work with files on external media that are larger than the free space you have left in your Journal. Step 4 could be better, as the icon for your Journal (appears in a bottom tray when additional media devices are present), is actually an XO kid icon, would be more logical to show the Journal icon I think. Step 3 clearly could be prettier but would require some way of generating live previews for the entries currently in view (and then you could use the proposed Journal grid view to view book covers). It's also worth noting that although directory structure of the external media is not displayed directly (Journal shows a flattened list of all files), the full directory path to the file is placed in its description field. This is all fully searchable data, so you could put all the Lewis Carroll books in a folder of that name, and that would be enough to allow you to query Journal for them. So just some well chosen directory names (by author seems sensible), and consistently well named files (i.e full title of book) would make quite an accessible solution. Perhaps if there's interest, we can polish some of the above steps to make it even smoother in 0.86? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Hi Sayamindu, On 23 Jul 2009, at 19:02, Sayamindu Dasgupta wrote: On Thu, Jul 23, 2009 at 9:03 AM, Gary C Marting...@garycmartin.com wrote: ..snip snip Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I think Read can be able to handle that. It means some extra work in the code, but it can be possible to extend the metadata in such a way that the state for each and every book in the bundle/collection is remembered. Of course you can hack on Read and make it handle all this bundle/ collection stuff :-) but my argument is Read should not really be doing this extra step. Journal needs to cover these features (whatever they resolve to be). Every activity author should not be inventing various implementations of a book shelf UI concepts for dealing with a monoculture 'collection' of objects. Imagine if I wanted to put together a 'collection' of Physics simulations to teach curriculum, or some Turtle Art projects teaching the idea of vectors, or a mix of both along with a book or two and a Labyrinth mind-map of topic notes. What happens if an Activity wants to use the ObjectChooser to pick an object buried in someone else's collection. A combination of a Journal grid view and correctly tagging objects would pretty much solve the UI side; with perhaps a bundle format (maybe repurpose .xol) so that downloading one auto extracted to a number of tagged Journal entries; and the reverse perhaps being true where you select N existing Journal entries and send to - ... causes them to be zipped up as a .xol and transferred as a single item. James' existing working solutions, Read EText, and Get Internet Archive Books (which BTW already downloads nice PDFs for Read to read), focus on using existing online resources for downloading new content to the Journal. This seems like a good Sugar Activity design pattern for cases where large online monocultures of resources already exist. Are you looking to fold his work into Read**? **I would have been great if Read had been extended, rather than a separate Read EText Activity created, but I guess that's water under the bridge now. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On 23 Jul 2009, at 21:36, Jim Simmons wrote: Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. Yes, book cover images, is the big missing feature with current Journal abilities when accessing external media (along with a Journal thumb view, but hopefully that feature is coming). The problem I have with USB devices on the Journal is that they are listed in descending order by the date and time they were created. Even a few hundred books on a USB stick isn't all that easy to manage. (I have an SD drive with 2 GB worth of comic books and it really bugs me that they aren't in alphabetical order). Searching is fine if you know what you're looking for. In this case the kid might be asked by his teacher to pick out a book from the conduct of life collection and do a report on it. The teacher asking students to pick out a book from the 'conduct of life' is the easy case :-) The kid just types 'conduct of life' into the Journal search filed, and just those books are listed. All that the USB stick would have needed is for those books to be in a directory called conduct of life, or for that text to be part of each books file name title. Like any real bricks and mortar library, putting the books in some sort of order, up front, really helps the punters in finding what they are looking for ;-) In that case the kid really needs to be able to search the USB drive as if it was a real bookshelf, look at the book covers, read descriptions, etc. What I had proposed would allow that. Yes, Journal type meta-data is not supported on external media unfortunately (though that is a really tough problem to solve). I guess you can make the argument for creating custom file layouts / index that you implement in Journal (E), so that you can stick book thumbs and metadata in known names/folders... But this is just a re-implementation of the data-store format from Tomeu, so no need to re-invent or re-implement, just use the existing format for free! What this would mean for the Journal is allowing external volumes/ media to be flagged in some way so that the Journal would read and display their data just like from the local Sugar data-store. I guess this could be very low hanging fruit, you'd need to ask Tomeu... The flag could be something as simple as an empty root level file on the volume named to indicate the volume is in data-store format and should be treated as such. The idea is to provide books to kids that don't have access to the Internet, either because it isn't available or because of parental concern. +1 Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
Gary, If it wasn't clear (because I started this discussion with Scotty elsewhere) my idea was to put the ebooks, cover images, and Dublin core catalog in a Zip file, then make an Activity that could read that Zip file, generate a GUI catalog as a sortable table with images, etc, in it, then let the kid select a book from that virtual shelf and make a copy of it to his Journal with all the metadata copied as well. What Get Internet Archive Books does for the website, this Activity does for these Zip files. The Journal is not asked to do anything. The zip file would be named conduct of life. You would have a bunch of zip files for different topics. These files would be distributed on USB sticks. Everything I have described could be made to work in .82. James Simmons On Thu, Jul 23, 2009 at 4:09 PM, Gary C Marting...@garycmartin.com wrote: On 23 Jul 2009, at 21:36, Jim Simmons wrote: Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. Yes, book cover images, is the big missing feature with current Journal abilities when accessing external media (along with a Journal thumb view, but hopefully that feature is coming). The problem I have with USB devices on the Journal is that they are listed in descending order by the date and time they were created. Even a few hundred books on a USB stick isn't all that easy to manage. (I have an SD drive with 2 GB worth of comic books and it really bugs me that they aren't in alphabetical order). Searching is fine if you know what you're looking for. In this case the kid might be asked by his teacher to pick out a book from the conduct of life collection and do a report on it. The teacher asking students to pick out a book from the 'conduct of life' is the easy case :-) The kid just types 'conduct of life' into the Journal search filed, and just those books are listed. All that the USB stick would have needed is for those books to be in a directory called conduct of life, or for that text to be part of each books file name title. Like any real bricks and mortar library, putting the books in some sort of order, up front, really helps the punters in finding what they are looking for ;-) In that case the kid really needs to be able to search the USB drive as if it was a real bookshelf, look at the book covers, read descriptions, etc. What I had proposed would allow that. Yes, Journal type meta-data is not supported on external media unfortunately (though that is a really tough problem to solve). I guess you can make the argument for creating custom file layouts / index that you implement in Journal (E), so that you can stick book thumbs and metadata in known names/folders... But this is just a re-implementation of the data-store format from Tomeu, so no need to re-invent or re-implement, just use the existing format for free! What this would mean for the Journal is allowing external volumes/media to be flagged in some way so that the Journal would read and display their data just like from the local Sugar data-store. I guess this could be very low hanging fruit, you'd need to ask Tomeu... The flag could be something as simple as an empty root level file on the volume named to indicate the volume is in data-store format and should be treated as such. The idea is to provide books to kids that don't have access to the Internet, either because it isn't available or because of parental concern. +1 Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On 23 Jul 2009, at 18:28, Gary C Martin wrote: Just wondering. If I had a USB stick with 2,000 pdf, plain text, etext, djvu, epub etc files on it... if they are at least reasonably well titled file names (lets say at least title, author), then a child can: 1). pop in the USB stick 2). goto the Journal and select the external USB stick icon 3). search and/or browse the books by author / title 4). any entry they want can be dragged to their Journal icon 5). ...or clicking any object entry will both start it for reading and copy it into the childs Journal Just to be clear, this is the behaviour since the data-store (and Journal?) re-work from Tomeu. I just ran the same test on an 0.82.1 release and had some different results: - I could rename, add tags, favourite and add descriptions; but this would appear as a duplicate entry on the stick next time I mounted the device. It would fail to start, but the old unchanged version would still be listed and would still work. Seem to remember this as an old indexing bug and part of the reason for the need to re-work the data- store to be robust. - resuming a pdf from the stick would view it in Read correctly but not copy the file over to the local data-store. When closing Read, it would then display a keep error (likely as the old data-store couldn't deal correctly with writing to external media). So, if you're looking to support deployments unwilling or unable to upgrade Sugar (likely a very large slice I'd imagine). This looks like you will need to bake your own Activity solution :-( Random thoughts. Both old and new external media support allows for starting an .xo Activity bundle. The Activity is installed and started. So you could extend the Get IA Books Activity to have a thumbnail view and have it check an external media device for a local archive format of some kind. Then just distribute a USB stick with the .xo bundle and the local archive of book content. Get IA Books Activity could then be launched, if found would default to the local archive, then any chosen books would be saved to the Journal. Both old and new external media also support for hiding files with the leading . (dot) character, so you could potentially hide the archive structure from the Journal view to prevent kids from clicking on it, just showing them the Get IA Books Activity icon. One unknown spanner in the works to test for, is what access restrictions an Activity might hit trying to arbitrarily read from an external media device, haven't had to do this myself. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On 23 Jul 2009, at 22:56, Jim Simmons wrote: Gary, If it wasn't clear (because I started this discussion with Scotty elsewhere) my idea was to put the ebooks, cover images, and Dublin core catalog in a Zip file, then make an Activity that could read that Zip file, generate a GUI catalog as a sortable table with images, etc, in it, then let the kid select a book from that virtual shelf and make a copy of it to his Journal with all the metadata copied as well. What Get Internet Archive Books does for the website, this Activity does for these Zip files. The Journal is not asked to do anything. The zip file would be named conduct of life. You would have a bunch of zip files for different topics. These files would be distributed on USB sticks. Everything I have described could be made to work in .82. Yes (finally) understood, I had missed the whole must work for 0.82, many apologies for the distraction – I've been looking at way too many 0.86 proposals et al :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Thu, Jul 23, 2009 at 4:44 PM, Gary C Martin g...@garycmartin.com wrote: Journal needs to cover these features (whatever they resolve to be). That would be handy. I would prefer a standard for /how/ to cover these features that indivicual activities can implement though -- this could let many people test out their own variation on user interface, various faster or more feature-rich indexing options, c -- without the barrier of saying 'you have to understand how to hack the Journal code to be able to work on this cool universal organizing/finding/editing-metadata problem'. A combination of a Journal grid view and correctly tagging objects would pretty much solve the UI side; with perhaps a bundle format (maybe repurpose .xol) so that downloading one auto extracted to a number of tagged Journal entries; and the reverse perhaps being true where you select N existing Journal entries and send to - ... causes them to be zipped up as a .xol and transferred as a single item. +1. The reverse is also very useful. Both old and new external media support allows for starting an .xo Activity bundle. The Activity is installed and started. So you could extend the Get IA Books Activity to have a thumbnail view and have it check an external media device for a local archive format of some kind. Then just distribute a USB stick with ... Both old and new external media also support for hiding files with the leading . (dot) character, Also sensible. SJ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Wed, Jul 22, 2009 at 06:31:18PM -0400, Samuel Klein wrote: This makes perfect sense to me. In particular, Read should be able to read .xol files and display books contained within them if they are in a known/readable format. Adding support over time for alternatives to catalog.atom would not be difficult (there are some learning-objects formats that have different canonical names and formats for their catalog files) but I'd like to see this become the recommended way to store a set of books, even if it is part of a more complex activity/object/content bundle. SJ On Wed, Jul 22, 2009 at 5:06 PM, Sayamindu Dasgupta sayami...@gmail.comwrote: Hello, While looking at the existing Library Bundle mechanism, I was wondering if it would be possible to bypass the Browser altogether and launch the catalog inside Read itself (for library bundles that have ebooks in them). If we use a zip archive format, with the following internal layout, it will be possible to load the catalog directly into Read (once I have support for the draft OPDS standard in Read): . |-- books | |-- Verne - 20,000 Leagues Under the Sea.epub | |-- Verne - A Journey into the Interior of the Earth.epub | |-- Verne - Around the World in Eighty Days.epub | |-- Verne - From the Earth to the Moon.epub | `-- Verne - The Mysterious Island.epub `-- catalog.atom Only the catalog name needs to be constant (catalog.atom) - the books would be referenced from the catalog, along with optional thumbnail icons etc. This may be useful in scenarios where the deployment or a distributor wants to distribute multiple (but of a similar theme) books together (eg: beginning of the school session, books for a specific subject). Does this make sense ? Thanks, Sayamindu IMHO, its really bad to not follow KISS(and UNIX way with small but powerful tools). Now we have list-of-objects/catalogs in Browse(for .xols), proposed catalogs in Read. At the same time we can provide catalog feature in Journal. I hope in 0.86 we will have more powerful filter[1]/tag[2] and thumbs[3] features. 0.88 could have Journal which would have plugins for specific needs like browsing books[4]. [1] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#What.2FAnything_palette [2] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tags_palette [3] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 [4] http://wiki.sugarlabs.org/go/Features/Unified_Browser_for_Objects -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Book bundles and Read
Hello, While looking at the existing Library Bundle mechanism, I was wondering if it would be possible to bypass the Browser altogether and launch the catalog inside Read itself (for library bundles that have ebooks in them). If we use a zip archive format, with the following internal layout, it will be possible to load the catalog directly into Read (once I have support for the draft OPDS standard in Read): . |-- books | |-- Verne - 20,000 Leagues Under the Sea.epub | |-- Verne - A Journey into the Interior of the Earth.epub | |-- Verne - Around the World in Eighty Days.epub | |-- Verne - From the Earth to the Moon.epub | `-- Verne - The Mysterious Island.epub `-- catalog.atom Only the catalog name needs to be constant (catalog.atom) - the books would be referenced from the catalog, along with optional thumbnail icons etc. This may be useful in scenarios where the deployment or a distributor wants to distribute multiple (but of a similar theme) books together (eg: beginning of the school session, books for a specific subject). Does this make sense ? Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
This makes perfect sense to me. In particular, Read should be able to read .xol files and display books contained within them if they are in a known/readable format. Adding support over time for alternatives to catalog.atom would not be difficult (there are some learning-objects formats that have different canonical names and formats for their catalog files) but I'd like to see this become the recommended way to store a set of books, even if it is part of a more complex activity/object/content bundle. SJ On Wed, Jul 22, 2009 at 5:06 PM, Sayamindu Dasgupta sayami...@gmail.comwrote: Hello, While looking at the existing Library Bundle mechanism, I was wondering if it would be possible to bypass the Browser altogether and launch the catalog inside Read itself (for library bundles that have ebooks in them). If we use a zip archive format, with the following internal layout, it will be possible to load the catalog directly into Read (once I have support for the draft OPDS standard in Read): . |-- books | |-- Verne - 20,000 Leagues Under the Sea.epub | |-- Verne - A Journey into the Interior of the Earth.epub | |-- Verne - Around the World in Eighty Days.epub | |-- Verne - From the Earth to the Moon.epub | `-- Verne - The Mysterious Island.epub `-- catalog.atom Only the catalog name needs to be constant (catalog.atom) - the books would be referenced from the catalog, along with optional thumbnail icons etc. This may be useful in scenarios where the deployment or a distributor wants to distribute multiple (but of a similar theme) books together (eg: beginning of the school session, books for a specific subject). Does this make sense ? Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On 22 Jul 2009, at 22:06, Sayamindu Dasgupta wrote: Hello, While looking at the existing Library Bundle mechanism, I was wondering if it would be possible to bypass the Browser altogether and launch the catalog inside Read itself (for library bundles that have ebooks in them). If we use a zip archive format, with the following internal layout, it will be possible to load the catalog directly into Read (once I have support for the draft OPDS standard in Read): . |-- books | |-- Verne - 20,000 Leagues Under the Sea.epub | |-- Verne - A Journey into the Interior of the Earth.epub | |-- Verne - Around the World in Eighty Days.epub | |-- Verne - From the Earth to the Moon.epub | `-- Verne - The Mysterious Island.epub `-- catalog.atom Only the catalog name needs to be constant (catalog.atom) - the books would be referenced from the catalog, along with optional thumbnail icons etc. This may be useful in scenarios where the deployment or a distributor wants to distribute multiple (but of a similar theme) books together (eg: beginning of the school session, books for a specific subject). Does this make sense ? Hmmm. The down side of this is that you end up with 1 Journal zip bundle holding a large number of books... So, I resume this zip bundle, pick one of the many books and start reading. I assume the single Journal entry is now remembering this one book and page I'm now reading. So now I want to read another book in the same bundle, do I loose the reference to the book and the page I was on before? Jump through some new UI hoops to flag the book and bookmark the page? It feels like walking into a Library, but only being able to read one book at a time. Successful Journal entries are the ones that store Activity state for some small slice of the goal, one book, not the whole library of congress. I'd be quite happy with zipped bundles that expanded into objects in the Journal, well tagged, nicely titled, and with thumbnails. That's where the big win is in my mind for distributing content. The xol was a reasonable idea, but narrow thinking, it missed the whole point of Sugar being centred around a core Journal where entries can make use of all the search, tagging, and preview features it offers for free. If the Journal managed to pick up a thumb/grid view in the 0.86 cycle, courtesy of Aleksey, then that view plus tagging (author, genre, et al) will make Journal your searchable book shelf, when you need it to be, and Read (or any other Activity) can focus on presenting great content well :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
