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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
