New database backend - testers needed

[theducks]

OK, I looked at a Good PI and a problem PI

version                 = PLUGIN_VERSION_TUPLE

is in the problem PI

[theducks]

Originally Posted by kovidgoyal

The deprecated plugins issue will be fixed in the next build (it is unrelated to the new backend, caused by some other changes I was making to the plugin infrastructure).

TNX

We are good bug finders

[BetterRed]

Originally Posted by kovidgoyal

@BR: Preferences->Look & Feel->Cover Grid

The image size settings baffled me - I don't think of images on the screen in terms of units of length, I think of them in pixels.

However, I think this would work better - display a sample cover in the default size and allow it to be resized on percentage basis - maybe with a slider widget.

Originally Posted by kovidgoyal

and if you want to select books, and make it visually obvious that they are selected use a search or a temporary virtual library. You can switch searching to highlight mode if you dont want the view restricted (though this only wrks in the book list, not the cover grid).

I don't think I am the only person who 'forgets' the search highlight button, maybe it needs a different icon

Temp Marker works fine with the highlight button in the Book List - just that I never wanted to use it there. In the Book List I always have it 'blue bars with red slash'.

Maybe you can devise a way of making 'blue bars only' work in CoverGrid View, I suspect I would use it there - I appreciate that might be counter-intuitive, but...

BR

[kovidgoyal]

Originally Posted by BetterRed

The image size settings baffled me - I don't think of images on the screen in terms of units of length, I think of them in pixels.

Well you should start thinking of them in units of length, that way if you move your settings to a computer with a monitor with different pixel density, they will still appear the same size.

However, I think this would work better - display a sample cover in the default size and allow it to be resized on percentage basis - maybe with a slider widget.

Sure, but that's also a lot more effort for a control that is not going to be used very often.

Search highlighting will work in the grid view as well, once I get around to it.

[kacir]

Originally Posted by kovidgoyal

@Krazykiwi: Never mind, I think I know what the problem is. It occurs if you try to merge two books that both have the same tag. Fix will be in the next build.

I had the same problem, I just couldn't reproduce it with any arbitrary pair of books. I was able to merge most books [that I tried], but a few produced similar error message. I was waiting with a bug report until I can reproduce steps to cause the bug.

[Divingduck]

Maybe something like a aspect ratio (4/3 etc.) can be a nice feature in the setup of cover sizes in the Grid view. A given width or hight calculate the rest if selected.

[Krazykiwi]

Originally Posted by kovidgoyal

@Krazykiwi: Never mind, I think I know what the problem is. It occurs if you try to merge two books that both have the same tag. Fix will be in the next build.

Ahh, that does make perfect sense. Dupes were in a new batch of books I imported, which got autotagged "CLEANME" on import. And as mentioned above, zapping the tags makes them merge quite happily.

And Kacir: it did look like it was any arbitrary pair for me, since.... well all the dupes I had to toy with triggered it.

Thanks again for all your fine work

[scissors]

Hi

thought i'd give it a try. All seemed fine until just.

After converting and AZW to Mobi and then trying to delete the original file i keep getting

calibre, version 0.9.42
ERROR: Unhandled exception: <b>LockingError</b>:can't downgrade SHLock object

Traceback (most recent call last):
File "site-packages\calibre\gui2\library\models.py", line 932, in data
File "site-packages\calibre\gui2\library\models.py", line 685, in func
File "site-packages\calibre\db\cache.py", line 54, in ans
File "site-packages\calibre\db\locking.py", line 208, in __enter__
File "site-packages\calibre\db\locking.py", line 79, in acquire
File "site-packages\calibre\db\locking.py", line 149, in _acquire_shared
LockingError: can't downgrade SHLock object

After setting new dbase to false and a restart the file deletes fine.

[BetterRed]

Originally Posted by kovidgoyal

Well you should start thinking of them in units of length, that way if you move your settings to a computer with a monitor with different pixel density, they will still appear the same size.

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

[theducks]

BR
I thought I was bad
2@ 1920x1080 (run at 1440x900 because of tired eyes)
and a old 1024x768 above (for notes/reference matl)

[kovidgoyal]

Originally Posted by BetterRed

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 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.

[kovidgoyal]

@scissors: That is the same error as reported here:
https://bugs.launchpad.net/calibre/+bug/1208470

It is being investigated, unfortunately, I am handicapped by not being able to reproduce it.

[BetterRed]

Originally Posted by theducks

BR
I thought I was bad
2@ 1920x1080 (run at 1440x900 because of tired eyes)
and a old 1024x768 above (for notes/reference matl)

The lenovo is a legacy of a former life, when I had a salary to sacrifice, a forgiving wife, and access to the bulk buy corporate price

[JimmXinu]

Originally Posted by kovidgoyal

You should not need to do anything at all. It may happen that some operations, typically updating a field in the database for many books, one at a time, becomes slower, in which case you should re-write it to use the new api. Other than that, you should not need to do anything, and that only if you or your users notice some slowness. Basically, where you had:

for book_id in book_ids:
   db.set_something(book_id, value)

replace it with

db.new_api.set_field(something, {book_id:value for book_id in book_ids})

Is this example the only recommended refactoring for plugins found so far?

Will it now be safe for PIs to skip self.gui.proceed_question() when updating the DB? (When using new DB, of course.)

Speaking of which, what's the best way for PIs to detect when the new DB is active?

Finally, a suggestion: I would change the name db.new_api (or make an alias for it) that doesn't have 'new' in it. db.api2 maybe. I can tell you from experience that having the word 'new' in your code after it's become old confuses people.
Someday :
"So new_api is the new API?"
"No, new_api is the old API. api3 is the new API."

[kovidgoyal]

Yes, that is the only recommendation, so far.

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.

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.

If you wish to check for the new api, just do hasattr(db, 'new_api')