On Fri, 09 May 2014 22:18:41 +0200 Thomas Martitz <ku...@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. -- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel