On 14-05-09 01:18 PM, Thomas Martitz wrote:
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
I think just the "extension points" need to be GObjects, for example, say we had a "code completion provider" API where plugins would be able to provide better completions for a particular language, we would have a "completion provider extension point" (IIUC). Other examples that we keep talking about being useful in Geany which would each require "tweaking" the existing code in the ways you propose specifically for proxy plugins include:
* Completion providers * Syntax highlighters * Filetype plugins * I had 2 or 3 more that escape me right now
b) It would breaks the plugin API in more ways. For example, plugin metadata shall be supplied via an .ini-style file.
It wouldn't have to severely break the API functions (eg. the stuff in geanyfunctions.h) but it would most certainly not be compatible with the part of the API used for loading/convenience like all the `plugin_*` functions.
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)
This is not only fairly trivial in C but many times more trivial in other languages (well at least in Python it's very simple, not sure about other languages).
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.
IMO, it wouldn't be a big deal as a "parallel" plugin system/mechanism, while just leaving the old one in place for some years as a "legacy C plugins API" (most of the API functions are just plain internal Geany functions, not so much work to maintain).
Anyway, I don't really care, but I just think we should consider all the problems with the current plugin API and when implementing something as you're proposing, not just hack on something for the one use-case but maybe think about something more extensible/useful in other contexts.
Cheers, Matthew Brush