On 26.3.2015 г. 01:16, Thomas Martitz wrote:
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?
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.
From your initial proposal:
"The plugin defines a single global function, geany_load_module(GeanyPlugin *, GModule *). This is the only function that geany learns about using g_module_symbol(). And the only thing this function ought to do is to call geany_plugin_register()."
As a non-Englisher, I read this as "the only thing must / should / is supposed / is preferable", and am not sure which one. Some of the meanings contradict "should be able to run arbitrary checking code".
But nobody can guarantee that it exists and is valid on init. [...] 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?
Emit a message in Status() + g_warning() and stop further init, plus check in cleanup(). A popup or status bar message would be acceptable too, since it's only if the plugin is actually activated, unlike any possible check in geany_load_module().
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.
Indeed. That's why I asked "please make this gboolean".
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.
OK then, that's it.
I also tend to think that a failing init is misdesigned. [...] 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.
Under the current loading mechanism, a plugin is re-loaded with g_module_open() on each toggle. If you intend to change that, you'll break any global variable initializations in all plugins, most importantly the assumption that a global C variable is automatically set to zero.
If you are going to open the module each time, but call load only the first time, the "loadable" state may be wrong if something has changed between the open-s.
(And if you assume that init may be called without load, how can a falling init be misdesigned? We can mask it as void, but failure is still a failure.)
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.
(yes, that's why I said "load the glade file and then unload it")
As a conclusion, a gboolean load is better than nothing. The resource errors in Scope were due to the fact that the resource directories defined by Geany were wrong. AFAICT, this is fixed in the latest gits, but a g_file_test() in init will still be helpful.
--