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. 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'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.
I said in my proposal it should do nothing but call geany_register_plugin(), but I guess we can relax that by allowing also for testing if the plugin itself is operational.
Best regards.