Hello,
I'm still working on proxy plugins, sorts of. I thought it would be useful to give you an update. I first taken my proxy-plugin approach to the final stages, and then went onto researching what we can do with libpeas and gobject based approaches. Please feel free to discuss things and/or contribute to my efforts.
In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins.
Since with that work you can successfully load python plugins I consider this approach workable. The code is on my github repo. The code is still in a proof-of-concept state with rough edges but I invite you to try it out. If you maintainers want to consider this for merging into geany proper then let's get this done, I'm all for it.
Now that the pluxy approach is in the final stages I went onto toying with libpeas.
Libpeas provides a nice interface for loadable plugins, both from the core's and plugin's point of view. For the core, plugins written in different language can be loaded through a unified interface. And plugins can implement multiple plugin entry points for different functionalities. Everything is based on gobject interfaces.
There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork.
1) backward-compat: Libpeas is fundamentally based on describing plugin metadata with a separate .ini-style file ($plugin.plugin). It cannot load plain .so files on its own. -> I solved this by extending the libpeas parser such that it can parse the plugin description of Geany plugins, and generate a PeasPluginInfo from it. This way we can load existing plugins before they transitioned to the .plugin file.
2) backward-compat again: libpeas' existing C parser cannot load the C plugins because they do not implement a gobject interface. -> For this I wrote a trivial custom loader which instantiates a "PeasGeany" interface instance (it has the traditional init(), configure(), help(), cleanup() methods) on behalf of the existing plugins.
with 1 and 2 i have successfully loaded existing plugins with libpeas.
3) access to Geany's plugin API for non-C plugins (aka bindings). -> This problem also applies to the plugin-proxy approach, except that for that it is mostly solved for python with geanypy. Anyway gobject-introspection provides a nice path to autogenerate language bindings. However, geany's API currently isn't introspectible.
3) is the problem I'm currently stuck at. I think Matthew already had an idea how we could possibly make it introspectible with little effort, with the help of vala. If anyone has other ideas or comments please speak up!
So, I do plan to make libpeas fully work as 3) would ultimately also help with the pluxy approach so it's a good idea regardless. Then we can have a look which of the approaches we want to merge for geany (if any (?)).
Best regards.