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