[Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

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.

--