Quote:
Originally Posted by DaltonST
Three plug-ins, CALM, ZMI and Library Codes now fail because they create mass quantities of new custom columns via calibredb.exe when initiated by the user Qt pushbutton action in the calibre.exe GUI.
ZMI also fails even if it already has its set of 26 custom columns because ZMI also uses calibredb.exe to Add Books.
CALM also uses calibredb.exe to add/move/delete/change books automatically among the Calibre library ecosystem.
|
You have been told multiple times that the correct way to add/move/change/delete books from a calibre plugin, is to use the database API rather than shelling out to calibredb.exe
Your failure to write good code is not an actual problem to be reported in this thread.
Quote:
|
Separately, and just as bad, using calibredb.exe to Add Books fails for ZMI too. That is the whole purpose of ZMI...to add Zotero documents to Calibre.
|
That isn't bad for calibre. calibre's purpose doesn't require your plugin, or else it wouldn't be a plugin, it would be a core feature...
There is no reason for Kovid to back out and ax an extensive new feature that adds things many many people have requested for years, simply because YOUR plugins break in the process.
Quote:
|
Your changes to calibredb.exe for Calibre 3 add no value to the many users of the above 3 plug-ins.
|
They add plenty of value. It simply happens that they
also break your plugins.
Quote:
|
You need to enable a new parameter for _init_.py files for plug-ins: maximum_calibre_version = (2, 98, 9) so the plug-ins that are deprecated by Calibre3 do not even load and cause confusing and non-fixable errors for the user.
|
That would imply that plugin authors would be willing to update their plugins to add incompatibility notices, but wouldn't be willing to actually fix their broken code.
calibre will not cater to this.
...
As for modifying a
different database than the one currently displaying in the GUI, check out how calibre itself performs the "Copy to library" action without shelling out to calibredb.
