[Geany-Devel] RFC: Proxy plugins
mbrush at xxxxx
Sat May 10 01:45:38 UTC 2014
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.
>> 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
> 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_*`
> 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
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.
More information about the Devel