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