[Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

On 19.3.2015 г. 00:05, 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". [...]
>>
>> 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.

It would be nice to unify such notifications. Of course, the plugins 
will need to return translated strings - we can't put their messages in 
Geany translation.

>
> 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.

There seem like two different things to me.

The first thing a loader needs to do is query each plugin for 
compatibility. Incompatible plugins should not be listed at all, and 
it'll be good if the loader emits status messages for them in the Status 
tab. As an alternative, they may be listed disabled, with a message why 
the module can't be used.

Now, do we really want the plugins to run arbitrary resource checking 
code, and display their own error messages, only because they are 
queried (or registered, as you put it), each time the list is build?

> I'm thinking if the plugin loaded successfully, then it should be
> operational too.

I can check if scope.glade exists, but is it valid XML, compatible with 
the current version of gtk_builder? The only way to be 100% sure is to 
actually load it. And them immediately unload it, because Scope is being 
queried only, not activated. And then load it again on init...

But nobody can guarantee that it exists and is valid on init. What if 
the Plugin manager is open, scope.glade is removed or altered, and then 
"[ ] Scope Debugger" is checked? It's low probability, of course, but 
how am I supposed to react - just crash? If init remains void, then it 
would be no better than the current void plugin_init(), and I'll simply 
check anything in load - why bother, if I *still* need to manually 
disable scope on initialization failure?

--
E-gards: Jimmy