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