[Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

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.