[Geany-Devel] Proxy Plugins Update

[Thomas Martitz]

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.