[GUI Plugin] View Manager

[Terisa de morgan]

It has worked for me now, thank you very much.

[BetterRed]

Originally Posted by JimmXinu

There's been a calibre change (in 2.10) that requires changes to some of the plugins to correctly support keyboard shortcuts. Specifically, plugins that change their menus dynamically.

I've been in touch with kiwidude, he doesn't have time right now to work on correcting these issues. But he has given the go-ahead for us (the PI dev community) to update them.

Attached is a version of this plugin I've updated. I've done some testing with it on calibre 2.10, 2.9 and 1.48 and it seems good. I'd like to hear if anybody has problems with it.

Confirmation that it fixes the shortcut issue for you would also be appreciated.

Seems to be working for me in 2.9 and 2.10 (32 bit)

BR

[BookJunkieLI]

Has anyone had issues with View Manager not implementing search restrictions while using Calibre 2.19? I use Calibre Portable on a Win7 Pro 64-bit machine and up until 2.19 I had no issues. But since I upgraded to 2.19 it won't implement the search restrictions - either as a basic search or as a virtual library. I have to manually select the virtual library/search myself every time I choose a new View. It's quite frustrating.

[BetterRed]

Originally Posted by BookJunkieLI

Has anyone had issues with View Manager not implementing search restrictions while using Calibre 2.19? I use Calibre Portable on a Win7 Pro 64-bit machine and up until 2.19 I had no issues. But since I upgraded to 2.19 it won't implement the search restrictions - either as a basic search or as a virtual library. I have to manually select the virtual library/search myself every time I choose a new View. It's quite frustrating.

@BookJunkieLI - no problems here. I don't use the search related settings in View Manager (VM) settings, and I always open libraries in a specific View and where appropriate in a specific Virtual Library.

However, after installing V2.19 a kb shortcut I had set up for one of my Views, which I use very frequently, stopped working. It had been 'taken over' by a new kb shortcut provided in the QuickView (QV) enhancements... quote:Version 2.19 "Quick view window: Allow the quickview window to be docked into the main calibre window.". I fixed it by removing the new QV kb shortcut and restoring my VM shortcut.

Aside : I wish calibre wouldn't do that, it's happened a couple of times recently. I was under the impression the unified kb shortcut mechanism was supposed to prevent it happening.

Maybe the QV changes are the cause of your problems. You can see the QV related changes at ==>> Commits · kovidgoyal/calibre. They're easy to spot as they have cbhaleys icon, I think the first QV related commit was on Feb 1.

The VM settings are stored in the library metadata.db files, you can see what's there in the corresponding metadata_db_prefs_backup.json files. I recall having a problem with VM (though I can't recall precisely what) that I fixed by removing the relevant entries in the json file, rebuilding the database via Library Maintenance->Restore database and then recreating the VM settings for that library.

BR

[BookJunkieLI]

@BetterRed - I took a look at the QV changes but honestly I didn't really understand what they actually meant so no idea if they're the cause of the sudden change.

I will take a look at the json file when I get home tonight and see if there's anything there that jumps out at as being the culprit. Question, would running the Restore Database from the command line be faster and/or less prone to the dreaded Not Responding?

[eschwartz]

Probably, because it won't have to render a GUI as well.
Although it won't show progress.

[BetterRed]

Originally Posted by BookJunkieLI

@BetterRed - I took a look at the QV changes but honestly I didn't really understand what they actually meant so no idea if they're the cause of the sudden change.

I couldn't see anything obvious there either.

Originally Posted by BookJunkieLI

Question, would running the Restore Database from the command line be faster and/or less prone to the dreaded Not Responding?

Not sure about the faster part, but you wont get a "not responding' at the command line, I think that's because cli proggies aren't in the message loop. I've never got a foggy screen in cmd.exe - now it's bound to happen

Suggestion: If the database rebuild doesn't solve the problem, install another edition (portable, 32bit whatever) for Version 2.18 and see if you get the same problems. If you don't then it would cast suspicion back on 2.19, but apart from QV (which isn't immediately obvious as a culprit either - aside from the fact that it nicked my ctrl/alt/p ) none of other changes look remotely related. .

BR

[BookJunkieLI]

@eschwartz - thanks for the info

Originally Posted by BetterRed

Suggestion: If the database rebuild doesn't solve the problem, install another edition (portable, 32bit whatever) for Version 2.18 and see if you get the same problems. If you don't then it would cast suspicion back on 2.19, but apart from QV (which isn't immediately obvious as a culprit either - aside from the fact that it nicked my ctrl/alt/p ) none of other changes look remotely related.

I took a look in the json and couldn't see anything there that would cause an issue, the settings for VM indicate it should be applying the search restriction. So, rather than possibly waste a bunch of time running a Restore Database I decided to install and compare 2.18 32bit vs 64bit vs Portable. Neither 32bit or Portable in 2.18 will apply the search restriction. 62bit does. I took a look at my downloads and it looks like I'd jumped right from 2.14 Portable to 2.19 Portable. I'm at work now but when I get home tonight I'll re-install 2.14 Portable and then progressively update to each version to see where the break happened. Not sure what that'll do for me but it'll be something.

[BetterRed]

Originally Posted by BookJunkieLI

I'm at work now but when I get home tonight I'll re-install 2.14 Portable and then progressively update to each version to see where the break happened. Not sure what that'll do for me but it'll be something.

If you can isolate it to say - "OK in 2.14 & 2.15" and "not OK in 2.16 on" and its repeatable then you can report it as 'bug' and Kovid should be able to fix it.

That you saw a difference between, Portable, 32bit and 64 bit seems a bit weird (Portable is 32bit repackaged).

You could create a clone of your library with a subset of your books to try the 'edit json, rebuild db, set up VM options' suggestion. For the VM problem I fixed that way, the metadata preferences backup looked OK, i.e. the JSON wasn't malformed or wrong in respect of values. But I noticed that the relative position of the VM settings in library A (where I had the problem) were different to library B (where I didn't have the problem); that's what led me to do the remove/rebuild/recreate for the VM settings in library A... which fixed the problem. But caveat emptor - my memory is fallible, so I may be misremembering.

BR

[BookJunkieLI]

I still need to do a little playing, because I only noticed it just before I had to leave for work this morning, but it looks likes VM's search restriction does work in 2.19, and everything prior to that, but only if you open a virtual library and close it before you select a View with a search restriction. Plus I think you need to do it with every new session. That's what I need to play with. The other option seems to be to do a Restore Database every time you open the library and, well, that's not gonna happen.

Without going all the way back to 2.0 I can't say for sure, but I wouldn't be surprised this if is a QT5 quirk because I know it's not an issue in 1.48. I use that pretty much every day at work and haven't had any issues with VM.

[BetterRed]

Originally Posted by BookJunkieLI

I still need to do a little playing, because I only noticed it just before I had to leave for work this morning, but it looks likes VM's search restriction does work in 2.19, and everything prior to that, but only if you open a virtual library and close it before you select a View with a search restriction. Plus I think you need to do it with every new session. That's what I need to play with. The other option seems to be to do a Restore Database every time you open the library and, well, that's not gonna happen.

Without going all the way back to 2.0 I can't say for sure, but I wouldn't be surprised this if is a QT5 quirk because I know it's not an issue in 1.48. I use that pretty much every day at work and haven't had any issues with VM.

See if this helps - https://www.mobileread.com/forums/sho...0&postcount=12

I think I was able to recreate your 'problem' on 2.19 and 1.48 by creating a View (Test) with a saved search, which worked as expected. But when I switched back to my Default view the saved search was still in force

So I ticked the Apply Save Search in the Default view settings but left the drop down blank. Voilà , if I switched from a view with a saved search, to one without, then no saved search was applied

I tested it with and without an active VL, seemed to work in both situations. I imagine you'd get similar behaviour with a Search Restriction as I got for Saved Search.

But the post I refer to above predates the existence of virtual libraries and Qt5, which makes me wonder if your VM settings at home and at work are the same, particularly regarding the Apply <search> settings.

I'm also wondering what purpose the check boxes actually serve, maybe all that's need are the values, where 'empty' means don't apply any search constraints.

BR

[BookJunkieLI]

@BetterRed - re: the post you referenced, that is discussing VM's behaviour when you switch from a View with a search restriction to one without, and yes, it appears that in order to negate it you either need to manually clear the virtual library/saved search or check the box for Apply search restriction without having an actual search restriction. In either case that's not the issue I'm having. The problem isn't going from one View to another it's when I first open my library.

I have a View called Finalization that I use in my editing process. It has ten columns selected for viewing and Apply Search Restriction: #done:false and series:false.

These are the steps to recreate the issue I'm having:
Step 1: Open up a library: it appears with the last columns that I had set to view, no virtual library active
Step 2: If I select a View with an Apply search restriction setting: the columns change to match that View settings but the search restriction is not applied.
Step 3: Apply a virtual library: can be any VL, it doesn't matter.
Step 4: Close virtual library: if I don't, on the next step VM assumes I want the View search restriction applied within that virtual library.
Step 5: Select the View I want to work with: the search restriction now works perfectly.

But the post I refer to above predates the existence of virtual libraries and Qt5, which makes me wonder if your VM settings at home and at work are the same, particularly regarding the Apply <search> settings.

That was one of the first things I thought of and checked. The VM settings, and the VL's, are exactly the same because I'm accessing the same library from both computers via a portable drive. At home I access it via Calibre Portable, currently 2.19. At work I have a desktop shortcut set to open Calibre 1.48 while using the --with-library command to specifically access the library on my portable drive.

[BetterRed]

Squarks - your this happens when I open the library penny hadn't dropped.

I'll try to repeat, might be tomorrow.

BR

[chaley]

I took a look at the code and there is indeed a problem that as far as I can tell has been there since 2010. Any attempt to set a search restriction before either the VL menu is opened or a VL is selected will fail.

I will submit a fix to Kovid.

EDIT: The fix is in current calibre source and will be included in the next release.

[BookJunkieLI]

Yay! Thanks, chaley.