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