On Fri, Jul 24, 2009 at 2:14 AM, Gary C Martin<g...@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 Martin<g...@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