[Geany-Devel] New plugin loader mechanisms
Dimitar Zhekov
dimitar.zhekov at xxxxx
Fri Mar 20 18:45:41 UTC 2015
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
More information about the Devel
mailing list