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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
