New database backend - testers needed

[DoctorOhh]

One last cosmetic issue with the Cover grid view. I love the default automatic settings the only thing that is a little wonky is the fact that the grid of covers always aligns to the left, so the right hand margin is often quite a bit bigger than the left hand margin. If there was a way to center the cover grid in the available space it might look cleaner.

[mbovenka]

Originally Posted by kovidgoyal

3) Fix adding books changing the case of existing tags/authors/series/custom columns/etc.

Fixed

[kovidgoyal]

@DoctorOhh: Sure, it was tricky to get Qt to do it, but I enjoyed the process https://github.com/kovidgoyal/calibr...dd4eafd47ea74a

[kovidgoyal]

@Adoby: 1 and 3, sure.

2) is not a good idea IMO as it will reduce performance for normal (post cache) usage and increase code complexity, simply to cater to a relatively rare event - resizing covers.

4) Having an optional tabbed interface for virtual libraries is interesting, but I dont see why it should be restricted to only the cover view,it would come in handy for the table view as well. However, I'm not promising anything, as implementing it will likely be a fair bit of work.

[Adoby]

Originally Posted by kovidgoyal

@Adoby: 1 and 3, sure.

Nice!

2) is not a good idea IMO as it will reduce performance for normal (post cache) usage and increase code complexity, simply to cater to a relatively rare event - resizing covers.

Sounds reasonable. Now the grid is new and invites to test with different sizes, but in the long run you will most likely stick to one size and the disk cache will not be invalidated often.

But the alternative I suggested could perhaps still be considerd? Precache just the next screen or two of covers in memory, in anticipation that the user will keep scrolling in the same direction after a quick look at the covers on the current view? A very likely event.

I have had more fun with the combination of the cover grid view and virtual libraries. And I notice a very clear difference between covers that are cached in memory or only on disk, and that is despite having the disk cache on a SSD. There is a slight delay when updating the screen going in one direction compared to when you go back, and can use the memory cache. I suggest that it would be a good use of the memory cache to precache and continue reading in covers from the disk cache to the memory cache in anticipation of another scroll being made.

But I agree that it isn't something that should be a priority, it is a rather minor thing. The cover grid is still pretty fast, even if it isn't always smooth.

4) Having an optional tabbed interface for virtual libraries is interesting, but I dont see why it should be restricted to only the cover view,it would come in handy for the table view as well. However, I'm not promising anything, as implementing it will likely be a fair bit of work.

A tabbed interface to the table view, as well, was a very intriguing thought! A tabbed interface would change how the user experience calibre quite a bit, and put a LOT more emphasis on the virtual libraries. Not something to change without careful deliberation.

But on the other hand, a tabbed interface is really only a much more convenient and intuitive way to switch virtual libraries, compared to the current method.

On the third hand it would also slightly reduce the size available to display both the cover grid and the table view. And it is likely that there will be many more virtual libraries than can be displayed at one time in a horizontal tab interface. I have already a lot more than that from having fun with the grid view.

When editing the settings for a virtual library, a simple checkbox to display the virtual library as a tab in the interface would be a very nice way to connect the virtual library to the interface, but that will most likely not be enough. Some way to order/group and switch virtual libraries in the tabbed interface would also be helpful or even needed.

But it is nothing to prioritise now, the current changes going on are already big enough for a update to 1.0. Enough to handle that...

[kovidgoyal]

The problem with precaching is that if you precache and the user does something else, you pay a performance cost, say you precache the next screen worth of covers and the user decides to do a search instead or change the sorting. Or jump several screens.

Then the render thread will have to finish rendering the precached covers before it can get to rendering the current screen of covers.

More importantly, scrolling just one screen of covers is instant with the disk cache (even on my three year old netbook), slowness only happens if you scroll through several screens at once, which precaching the next screen wont help with anyway. The only way around that is to increase the size of the memory cache and pre-fill it, which wastes *a lot* of RAM and CPU.

To put it another way, I can scroll through the disk cached covers at a speed that is faster than my eye can follow. Which is fast enough.

[Adoby]

I obviously need to do some checking to see if there is some problems with my setup. For me the disk cache seems a little bit slow. Noticeable slower than the memory cache.

Could there be some slowdown of the disk cache for very large libraries?

[kovidgoyal]

As far as I know, the disk cache should perform fine for large libraries., unless you are running out of space, in which case try increasing the maximum disk cache size.

[DoctorOhh]

Originally Posted by Adoby

I obviously need to do some checking to see if there is some problems with my setup. For me the disk cache seems a little bit slow. Noticeable slower than the memory cache.

Could there be some slowdown of the disk cache for very large libraries?

I have about 10000 books and the disk cache is very fast off of my normal drive. It was only slow when first cached. It seemed this required me to actually view every part of my library, but once all was cached to disk it fills in faster than I can view any of the back title and author wording, even if I scroll down many screens. The nice thing is that it persists between restarts.

[BetterRed]

FWIW - I think a dual pane interface to two physical libraries would be more useful than virtual library tabs. I appreciate that ain't easy.

If folks are creating lots of VL's then a vertical tabstrip might be better than a horizontal tabbar. It can be put in a split container with a scroll bar when required, and it can use flyouts if the container is too narrow to display the full name, it's hard to do equivalents with a horizontal tabbar. Also monitor aspect ratios are trending wider rather than deeper.

Also - I thought there was a 'display cover full size' feature somewhere in Calibre, but maybe I imagined it - anyway I thought it might be useful to have in the cover grid.

I think I saw a request for a one pixel border to indicate the book is on the current device, IMO it would be hard to discern such a border on a half decent high res monitor. I suggest as ebook reader icon in a corner - let user chose size.

BR

[Adoby]

An overlayed ebook reader icon would most likely work better than both a 1px border or another background color. It would be more obvious.

With the new database backend I would suspect that it might soon become possible to have more than one instance of calibre running at once? That would enable you to have more than one "real" library open at the same time.

Then after that all that is needed is "just" to implement drag-and-drop and copy-paste between instances.

[kovidgoyal]

On device is indicated by the same tick mark icon as is used in the table view. And it is added to the tooltip as well.

[DoctorOhh]

Originally Posted by kovidgoyal

On device is indicated by the same tick mark icon as is used in the table view. And it is added to the tooltip as well.

Good choice, simple, consistent.

[BetterRed]

Running multiple instances of the same proggie is a bit yesterday. IIRC the main 'killer' feature of Firefox was its tabbed browsing.

Dragging things around with a mouse is a good way to lose them - particularly between program instances, you have the problem of the source stealing focus and hiding the target when you start dragging stuff.

With a dual pane interface you could copy (or move) a book to the other library by clicking a button, or by using the context menu, or by doing as I do in my dual pane file damager - F5 to copy, F6 to move current item(s).

BR

[Adoby]

Ah... Another Norton Commander survivor. I get my fix mostly on Midnight Commander nowadays.

Firefox allows to both run separate instances and in tabs. The ability to have more than one instance of calibre running at the same time would most likely be helpful for a tabbed interface for separate libraries as well. Just a guess.

It might be confusing with both real libraries and virtual libraries in tabs? Copy-paste or f5/f6 only makes sense between real libraries, not between virtual libraries in the same real library. Or even to a virtual library in another real library, the change might not be visible.

But I feel we are going out on a tangent here. This is hardly relevant for the current upgrades. But still fun to see that there are a lot more changes to speculate about.