On 15-03-18 03:05 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...] void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI, but be unable to startup / initialize for some reason. For example, Scope requires scope.glade in the plugin data directory).
+1, I've always wanted a way to signal Geany "don't bother, it's just going to crash you if you keep going". The only way I can see to handle critical failures without a status return from there is to keep a global variable and guard each function so it can't execute its normal code, which is a bit of a pain and weird for users if the plugin loads but doesn't do anything.
Another useful thing might be to provide a way to return a reason message as well, then when Geany gets the failure return it can open an error dialog and show the user a message that the plugin couldn't be loaded, and show the reason string and maybe some bug-reporting info or something.
Thinking about it, if the plugin can't run because it's missing resource files required for its operation, then I think it should be treaded like incompatible plugins. This has the benefit that they will be attempted to be loaded on the next startup if the user had previously selected it.
For resource files like say a GtkBuilder UI file, I'd agree, but there may be some other cases, for example if a plugin dynamically loaded some particular library (or variant of a library) based on user configuration, it'd be useful to report to the user that the library is wrong, or no longer available, or whatever.
Incompatible plugins simply return false in geany_load_module() [I've implemented a safety guard geany_load_modules() even though the abi/api version check failed]. The plugin can also print the reason to stdout/msgwin/error dialog from within that function, although IMO a dialog is too intrusive.
I generally hate dialogs, but I think a plugin failing to load is a fine use for one since it doesn't happen with high frequency, and just dumping g_critical() or equivalent on the console is useless/confusing if the user hasn't launched from a terminal (and doesn't realize about Help->Debug Messages).
I'm thinking if the plugin loaded successfully, then it should be operational too. Meaning that init() should not fail, but simply activate the plugin. As outlined above, my proposal already covers the case "compatible but not operational due to missing runtime dependencies" you described.
For cases like GeanyPy which loads arbitrary Python scripts (which are even fully executed on import), and in a language where Exceptions are common (especially during development), it would probably be useful to signal that the plugin script couldn't be loaded and maybe even be able to provide a formatted traceback of the Python exception or such.
Cheers, Matthew Brush