Covers-only browsing view

[stuartlangridge]

If beru had the option of showing only covers at larger size for books in a GridView, that would make it more acceptable to people who tend to think that way, and prettier to boot. Most existing ebook readers provide this sort of view (as the default!), although many do use the "sitting on a shelf" wood texture background which is probably a step too far.

Irritatingly, this would require some fiddling because it'd require changing the listview item from being a listview to being a gridview -- more accurately, it would require having both a listview and a gridview around and switching between them, and changing sort orders in both. (Thought: is a gridview with its delegate the width of the screen effectively a listview?)

[rschroll]

On Thu, Sep 12, 2013 at 5:32 AM, stuartlangridge notifications@github.com wrote:

Irritatingly, this would require some fiddling because it'd require changing the listview item from being a listview to being a gridview -- more accurately, it would require having both a listview and a gridview around and switching between them, and changing sort orders in both.

It wouldn't be that bad, I think, especially if we manage to use the same models for both. Another way to do this would be to make the cover view act as another sort option. If you're sorting by title or author, you're thinking verbally and probably not as interested in big pictures.

The detail I'm more worried about is how to store the cover images. Right now, they're stored base64-encoded in the database. To save space, we only save a low-res version, big enough only for the little icon. I don't know what the implications of saving larger images in the database are. Other options would be to store the images in a configuration directory somewhere instead of the database or to store the location of the cover images within each epub and read them directly from there each time we need it.

[stuartlangridge]

You are in fact correct, hooray; I've just poked my local copy here to do this and it's fine. (The secret is this: change the ListView to be a GridView, and set cellWidth to parent.width for the existing delegates, and something smaller for the new coverDelegate. I can push to a fork if you'd like, but I only did this to prove the point.)

Good point on the imagery, though. The way to do this would be to save the larger images in the app's own private folder, but you can't yet do that from QML with the Ubuntu SDK, annoyingly. (It is coming, I am told.) Opening up the epubs every time will be deathly slow (because you only need this when you are looking at a screen full of images!) so that's not the way. Storing larger images in the database, also base64ed, might be the way, I suppose. I can't see a big reason why that'd be a problem; I mean, it makes the DB bigger, but it shouldn't significantly decrease the time taken to query the DB (that's what indexes are for), and if it's avoided by storing on the filesystem then you're still using the same amount of storage, just in a different place.

On Thu, Sep 12, 2013 at 11:55 PM, rschroll notifications@github.com wrote:

On Thu, Sep 12, 2013 at 5:32 AM, stuartlangridge notifications@github.com wrote:

Irritatingly, this would require some fiddling because it'd require changing the listview item from being a listview to being a gridview -- more accurately, it would require having both a listview and a gridview around and switching between them, and changing sort orders in both.

It wouldn't be that bad, I think, especially if we manage to use the same models for both. Another way to do this would be to make the cover view act as another sort option. If you're sorting by title or author, you're thinking verbally and probably not as interested in big pictures.

The detail I'm more worried about is how to store the cover images. Right now, they're stored base64-encoded in the database. To save space, we only save a low-res version, big enough only for the little icon. I don't know what the implications of saving larger images in the database are. Other options would be to store the images in a configuration directory somewhere instead of the database or to store the location of the cover images within each epub and read them directly from there each time we need it.

— Reply to this email directly or view it on GitHubhttps://github.com/rschroll/beru/issues/16#issuecomment-24362184 .

New Year's Day -- everything is in blossom! I feel about average. -- Kobayashi Issa

[stuartlangridge]

(Have forked at https://github.com/stuartlangridge/beru and that contains a simple example of the cover browser, with obviously blurry images)

[rschroll]

Cool to see that this can be done easily. Some random thoughts in no particular order:

• Should this just replace the recently-read sort? I don't know that there's a need for both.
• I know nothing about databases; hence my vague worries about performance. A simple way to test would be to save larger versions in the existing database. At the very end of EpubReader::getCoverInfo(), change the first argument of coverimg.scaledToWidth from 5*guscale to some appropriately large number. Delete the database (or back it up somewhere), and see how the performance compares with the large images.
• We're parsing the cover info in C++ anyway, so writing a cached version of the file directly from C++ would be easy, and we wouldn't have to worry about file access from QML.
• To get the cover info, we need to open a Epub file, read and parse 3 xml files, read and do a cubic resampling of an image, and write to a database. This all happens in ~100ms. So I'm not entirely convinced that reading an image from the Epub will be too slow. (Though the phone will be slower, which is something I need to remember.)
• Should the title and author appear below the book cover in this view?
• What should we do for missing covers? The B icon is okay at the small size, but probably won't look so hot larger. Perhaps we can make up a fake cover using the title and author together with the icon.
• Along those lines, what do we do with those books that are giving us errors?

This would be lovely to get in in time for the showdown, but I have a feeling I'll be spending the weekend bug squashing and won't have time for it. :(