[Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Fri, 09 May 2014 22:18:41 +0200
Thomas Martitz <kugel at rockbox.org> wrote:

> Am 08.05.2014 02:33, schrieb Matthew Brush:
> > Hi Thomas,
> >
> > Disclaimer: I'm not a LibPeas expert or even user but from what I've 
> > read about it (the docs, tutorials) it sounds like pretty much exactly 
> > the end-goal we want for Geany plugins.

Read the documentation. It's only 6 base classes, 2 interfaces and 2
widgets. The widgets form simple plugin manager, but they are
completely optional, we can write our own using the current UI.

> Right, LibPeas was repeatedly suggested already. However, the first 
> reply was always "uhm it would probably require a massive rewrite" which 
> is kind of showstopper given how hard it is to get changes into the core.
> 
> Anyway, I have still looked into it and came to the conclusion that it's 
> not a good fit either way, for several reasons. Please correct me if I'm 
> wrong.
> 
> a) All API entry points have to be gir-introspectable, .i.e. 
> gobjectified. This is probably the massive rewrite that was suggested. 
> This also implies massive plugin API/ABI breakage

For C plugins, we just need to pass geany_data and geany_functions.
See peas-demo-window.c: peas_extension_set_foreach(),
g_signal_connect("extension-added") and the demo plugins.

For python, maybe we can include geanypy/src/*.c in Geany or in
a .so library. But if we don't want to end up with more 150+ KB proxies
like geanypy, we'd better use introspection. I really admire Matthew
and Lex for writing this thing, but that's hardly the best approach,
and I don't expect many people to repeat it and maintain such proxy.

> b) It would breaks the plugin API in more ways. For example, plugin 
> metadata shall be supplied via an .ini-style file.

Moving a few strings from foo.c to foo.ini will hardly be a problem. :)

> c) Plugins need to implement and expose a new gobject in order to be 
> even recognized as plugins (PeasEngine recognizes plugins/extensions by 
> their GType)

For C, it can probably be handled by 2 macros, REGISTER_PLUGIN and
REGISTER_PLUGIN_WITH_CONFIGURE. Our current plugins don't support
Activate, and the Help in peas is an URL, not a function.

> After that I'd say that LibPeas is perhaps something to be considered 
> for new application but not for our existing codebase. I think we want 
> something that enables proxy plugins while maintaining API and ABI 
> stability.

peas does does you describe, and provides build-in loaders for Python
2/3 and JavaScript, i.e. standard languages. Please don't throw it away
before even trying to adapt it.

-- 
E-gards: Jimmy