[Geany-Devel] RFC: Proxy plugins
dimitar.zhekov at xxxxx
Sat May 10 19:06:32 UTC 2014
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
> 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
peas does does you describe, and provides build-in loaders for Python
before even trying to adapt it.
More information about the Devel