[Bookreader] [Sugar-devel] Book bundles and Read

Sayamindu Dasgupta sayamindu at gmail.com
Fri Jul 24 18:57:59 EDT 2009

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


Sayamindu Dasgupta

More information about the Bookreader mailing list