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.