Quote:
Originally Posted by JimmXinu
DaltonST,
What is the mechanism that JS+ uses to change Views on VL change? If we do add a change-VL feature to VM, how do we prevent recursion?
|
JimmXinu:
No worries.
The JS+ GUI Tool to change the View based on VL is invoked explicitly by the user in either of two ways, both of which are shown in the attached image in my post of yesterday:
[1] The user clicks a Favourites shortcut to the GUI Tool's menu item; or,
[2] The user clicks
and immediately releases the Calibre GUI "Virtual Library" button. The resulting Qt "released" event for that pushbutton is connected to the same function as the Favourites shortcut, which is also the same function as if the GUI Tool action were invoked directly from the JS+ Menu itself.
Obviously, the user must also have activated that entire GUI Tool by clicking its checkbox to do so in JS+ customization. Nothing happens if they choose to not use it.
So, the user selects the VL, and then intentionally causes the JS+ GUI Tool to activate the matching VM View by a click or a click-and-release, depending on what they clicked.
That is the opposite of what Tanjamuse is describing. She wants to select the VM View, and have VM activate the matching VL automatically once the selected VM View becomes active. That provides her a "one to many" mapping capability of VL to View that she needs. JS+ only does "many to one".
From what I see, the VM plug-in just needs a new "Apply Virtual Library" checkbox and dropdown à la "Apply Saved Search", and then apply that VL whenever a VM View is chosen.
Tanjamuse can then map as many Views as she pleases to the identical VL.
In summary, the described new VM functionality in no way interferes or collides with the JS+ functionality. Both can be used simultaneously if the user can remember what-is-what. It really depends on whether their VLs are "specific" and their Views are "generic", or vice-versa. JS+ implicitly assumes the former, and VM's new functionality would implicitly assume the latter,
DaltonST