[Geany-Devel] New plugin loader mechanisms

[Matthew Brush]

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