New database backend - testers needed

[mbovenka]

Originally Posted by kovidgoyal

@mbovenka: https://github.com/kovidgoyal/calibr...7326997fa21eeb

[JimmXinu]

Originally Posted by kovidgoyal

proceed_question() was never only about thread safety, since the updates all happen in the gui thread anyway. So you still need to use it. Think about what happens if the user has the edit metadata dialog open for a book that you are updating in the background, either the users' changes or yours would get obliterated.

True. The situation is the same with calibredb CLI updates--although probably with a smaller and more savvy user base. Oh well, I was just being hopeful.

Originally Posted by kovidgoyal

Considering that this new api took almost two years to develop, I dont think I will ever do this again But, if I do, I'll deal with any resulting confusion.

Fair enough.

I've not run into any problems using the new DB yet, but my testing has been pretty light--just day to day stuff.

[gbm]

Originally Posted by BetterRed

No need for me to wait to get another computer I have three monitors available on the one I am using. If I were to run Calibre on the 22" Lenovo I would want to see more covers than I would on the 30" Dell - the Lenovo is 3840x2400 pixels, the Dell is 2560x1600pixels. If I run Calibre on the 24" Samsung at 1920x1200 then I'd probably want to see about the same as I would on the Dell - the Samsung normally being a lot closer than is the Dell.

Viewing comfort is at least as much a function of pixel density, the dot pitch and the distance between the eye and screen, as it is on screen size - I would argue more so.

I used an image editor to work it out, easier than doing the sums in my head - now I have a 12x5 grid on the 24" 1920x1200 Samsung. Next time I run Calibre on the other monitors I'll work out a good size for them and write it down - somewhere

I worked on hi-end imaging system for a decade or so, back then we only thought in units of length when we printed images for situation room briefings. AFAIK camera's and scanners still work in pixels - even the ones on fiddle fones - never mind.

BR

I am using a cheap 24" HDTV at 1368x758. Have found a size of 2.5 cm x 3 cm is good.
Gives me a 3x10 grid (3 up and 10 across).
bernie

[BetterRed]

Originally Posted by kovidgoyal

I for one look at all my different monitors at the same distance, and I like to adjust things so that they are equally legible at that distance on all monitors, regardless of their resolution.

Mine serve different functions, the Dell is on wheels with wireless connect, its mainly used to watch things, rather than do things. I use the Lenovo in a low light area for precision editing, the Samsung is for every day stuff.

I also use the Dell in situations where otherwise I might have people looking over my shoulder - they can sit and watch the Dell and see what I'm doing, usually on the Samsung.

BR

[DoctorOhh]

Originally Posted by theducks

Why have both the Cover Browser AND Grid View?

Kovid already answered this, but another answer comes to mind which is the Grid view is not yet quite up to speed.

I can scroll to any point in the list view, click on a book and the covers will fill in virtually instantaneously on the cover browser. OTOH when running the Grid view I can scroll to a location, click on a book and it will take anywhere from 10-40 seconds for the covers to fill in. This occurs using the scroll wheel on the mouse or grabbing the slider with the mouse and moving it to a given point.

Ideally at some point the grid view can be optimized to keep up with the scroll wheel.

My Specs:

Windows 7 64bit
Calibre Portable 32 bit ver 0.9.42
i7-2600 CPU 3.4 GHz
8 GB of ram

[kovidgoyal]

@DoctorOhh: That's a limitation of the way list views in qt work. If you scroll continuously all the covers between the start and the end point have to be rendered, which can take a while. It may be possible to do some hackery to delay rendering until scrolling "stops", but that may not be possible to implement robustly.

[DoctorOhh]

Originally Posted by kovidgoyal

@DoctorOhh: That's a limitation of the way list views in qt work. If you scroll continuously all the covers between the start and the end point have to be rendered, which can take a while. It may be possible to do some hackery to delay rendering until scrolling "stops", but that may not be possible to implement robustly.

Such is life. I don't see the grid view being my main view. But after you add author (or author sort) to the underlying text view who knows.

Thanks for the ever expanding set of options.

[BetterRed]

Originally Posted by DoctorOhh

Such is life. I don't see the grid view being my main view. But after you add author (or author sort) to the underlying text view who knows.

@DoctorOhh & theducks - the CoverGrid & CoverBrowse Views can be used concurrently - they are not alternatives - that's reason enough for having them both.

I upped the CoverGrid cache to 1000 covers, in the Grid I can scroll through 650 covers in 2½ rolls of the wheel - and the CoverBrowser stays in synch. Takes 'too many to count' rolls to scroll through the same number of covers in the CoverBrowse View

I found some functional reasons I don't use the CoverBrowse View -

• can't find a way to turn off the left click action - open book in first available input format
• have to maintain a separate context menu.

If the CoverGrid gets a separate context menu, could an option be provided to use the one set up for the Book List.

BR

[DoctorOhh]

Originally Posted by BetterRed

@DoctorOhh & theducks - the CoverGrid & CoverBrowse Views can be used concurrently - they are not alternatives - that's reason enough for having them both.

I use the cover browser and the list view concurrently. To swap out the list view for Grid view would just seem silly. So in my opinion they are alternatives to each other.

But Kovid stated the only real reason for keeping the two "Because different people have different preferences." To which I agree, wholeheartedly.

Originally Posted by BetterRed

I upped the CoverGrid cache to 1000 covers, in the Grid I can scroll through 650 covers in 2½ rolls of the wheel - and the CoverBrowser stays in synch.

Calibre does not cache the grid view in advance, so if you open calibre any scrolling in grid view will out pace the covers being populated. Now if calibre could cache half ahead and half behind the current position then the problem of the covers taking their time to catch the scrolling wheel would mostly go away if you made the cache large enough. Currently it looks like 3000 is the highest cache allowed.

Originally Posted by BetterRed

Takes 'too many to count' rolls to scroll through the same number of covers in the CoverBrowse View

But if you slide the scroll bar (of the list view) you can go as far as you want in a blink, click a book and the covers populate immediately.

[theducks]

I did know the Cover and Grid views could be active at the same time (I tried it).

(thinking in advance to the full production release )
I had been thinking more about the button to Activate, Why use 2 buttons?

With either Grid or Cover:
You see the cover
You can use the (right-click) Context menu
You can VIEW Metadata either by context or, if the details pane is active, Details.

What you can't select is SORT. (Going back to BR's use of context menu). Right click ON book = current Context. Right-click in open space= Sort Context (not exactly the same as what you get when you click on a header, but close. You will need to specify on which field to sort. Sort ▲:<list>, Sort ▼:<list>)

Another optional Auto appear (after time delay) of Details/Info view for a selected book. Second option to then auto-hide (after preset time)

[kovidgoyal]

@theducks: You can right click to sort already. And there is not going to be a separate right click menu depending on where you click, that is confusing and fragile.

[theducks]

Originally Posted by kovidgoyal

@theducks: You can right click to sort already. And there is not going to be a separate right click menu depending on where you click, that is confusing and fragile.

I am blind

[kovidgoyal]

Originally Posted by theducks

I am blind

It's easy to miss, at the bottom of the menu, but putting it at the top would cause the positions of other entries to differ between the table and grid views, which is not good.

[BetterRed]

Originally Posted by kovidgoyal

It's easy to miss, at the bottom of the menu, but putting it at the top would cause the positions of other entries to differ between the table and grid views, which is not good.

I open the context menu via the Menu key on the keyboard, for ergonomic reasons I put the options I use most often at the bottom of the menu. So I would like to be able to move Sort By up the list, or send it to the Available Items list.

Which begs the question, why shouldn't Sort By be available in the BookList View - it has columns that the user may not ordinarily display in the list, it may be useful to be able to sort on those columns on an ad-hoc basis - eg when looking for outliers based on Size.

BR

[theducks]

Originally Posted by BetterRed

I open the context menu via the Menu key on the keyboard, for ergonomic reasons I put the options I use most often at the bottom of the menu. So I would like to be able to move Sort By up the list, or send it to the Available Items list.

Which begs the question, why shouldn't Sort By be available in the BookList View - it has columns that the user may not ordinarily display in the list, it may be useful to be able to sort on those columns on an ad-hoc basis - eg when looking for outliers based on Size.

BR

BR
In windows, you can be viewing thumbnails and sort by many other items you can't see.

I have been thinking over Kovids comment.
IMHO Sort 'does not fit in with all the other Context on the menu.
They all apply to the BOOK(S)
Sort applies to the Grid.

And I had to stop and think about 'Reverse' when I saw it