[Geany-Devel] RFC: Proxy plugins
Thomas Martitz
kugel at xxxxx
Fri May 9 20:18:41 UTC 2014
Am 08.05.2014 02:33, schrieb Matthew Brush:
> Hi Thomas,
>
> If the goal is really to enable loading plugins written in other
> languages, we should take a really extensive look at LibPeas before
> ruling it out and duplicating it ourselves. It seems especially
> appropriate since you want to eventually get multi-language support
> into core, and it provides a small library we can have a hard
> dependency on that (IIUC) itself has soft-dependencies on all the
> stuff we don't want to require for Geany (language runtimes,
> interpreters, etc.).
>
> 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.
>
> My $0.02.
>
> Cheers,
> Matthew Brush
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
b) It would breaks the plugin API in more ways. For example, plugin
metadata shall be supplied via an .ini-style file.
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)
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.
Best regards.
More information about the Devel
mailing list