[Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov:
>
>>
>> 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?

They [incompatible plugins and plugins that are unable to function due 
to missing runtime deps] are different things, but the resulting action 
should be the same (hide it from the PM dialog, possibly give the user a 
hint). Hiding from the PM dialog should IMO be done before it even 
showed up, to avoid creating expectations that cannot be met and 
negative user surprise.

Yes plugins should be able to run arbitrary checking code because that's 
necessary for proxy plugins. Whether Geany can provide APIs to report 
results to a the user in a consistent manner is on another piece of 
paper, one that's IMO slightly out of scope for my proposal.

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

My opinion is that if the XML isn't compatible to the current GtkBuilder 
version then scope shouldn't even show up in the PM dialog, because 
there is no way it can be functional. This is not fundamentally 
different to a plugin being incompatible to Geany's ABI version. So yes, 
that implies validating the XML in geany_plugin_register() (although 
loading seems excessive to me, because the XML should be considered 
distributed with the plugin and not to be edited by the user; at some 
point you have to make some assumption to keep problems managable).

If this seems so inefficient you could try to rescue the state from 
geany_plugin_register() to init. However keep in mind that init can be 
called without prior call to geany_load_module(), if the user toggles 
plugins in the PM dialog. And that init might not be called at all, so 
plugins shouldn't be wasteful with resources in geany_load_module() if 
might never be needed.

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

What do you do currently?

Besides, I didn't mean to make init() any better than the current 
plugin_init() w.r.t. to its semantics. The only difference is more/other 
parameters.

Geany does not handle failing init() currently, and I don't want to 
change that now because I think that's out of scope for my proposal. I 
merely want to transform the current hooks into a new mechanism without 
introducing large discrepancy between the two mechaisms (because the 
current one will be still supported). I also tend to think that a 
failing init is misdesigned.

What do others think about this point?

Best regards.