[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