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.