View Single Post
Old 09-12-2019, 11:51 AM   #23
eschwartz
Ex-Helpdesk Junkie
eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.
 
eschwartz's Avatar
 
Posts: 19,421
Karma: 85400180
Join Date: Nov 2012
Location: The Beaten Path, USA, Roundworld, This Side of Infinity
Device: Kindle Touch fw5.3.7 (Wifi only)
@jackie_w, @kovidgoyal,

Am I missing something? Surely the run_calibre_debug process, which is executing code imported from the calibre plugin itself, likewise has access to all plugin resources, and especially the ability to access plugin utilities that extract an image file from the plugin.

The only thing the subprocess *won't* have is the ability to share internal state and memory, and thus, the ability to have a writable handle on the metadata.db.

It should be literally the same as running the plugin normally, but launched from a custom QApplication rather than calibre's.
In general, I don't think there is a reason that calibre-debug --run-plugin should be unable to import all Calibre code, consult the constant variable which says "here is where the user config dir is", or execute the same functions that are available to the GUI.
eschwartz is offline   Reply With Quote