On Fri, 09 May 2014 22:18:41 +0200 Thomas Martitz kugel@rockbox.org wrote:
Am 08.05.2014 02:33, schrieb Matthew Brush:
Hi Thomas,
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.
Read the documentation. It's only 6 base classes, 2 interfaces and 2 widgets. The widgets form simple plugin manager, but they are completely optional, we can write our own using the current UI.
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
For C plugins, we just need to pass geany_data and geany_functions. See peas-demo-window.c: peas_extension_set_foreach(), g_signal_connect("extension-added") and the demo plugins.
For python, maybe we can include geanypy/src/*.c in Geany or in a .so library. But if we don't want to end up with more 150+ KB proxies like geanypy, we'd better use introspection. I really admire Matthew and Lex for writing this thing, but that's hardly the best approach, and I don't expect many people to repeat it and maintain such proxy.
b) It would breaks the plugin API in more ways. For example, plugin metadata shall be supplied via an .ini-style file.
Moving a few strings from foo.c to foo.ini will hardly be a problem. :)
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)
For C, it can probably be handled by 2 macros, REGISTER_PLUGIN and REGISTER_PLUGIN_WITH_CONFIGURE. Our current plugins don't support Activate, and the Help in peas is an URL, not a function.
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.
peas does does you describe, and provides build-in loaders for Python 2/3 and JavaScript, i.e. standard languages. Please don't throw it away before even trying to adapt it.