Am 11.07.2014 22:03, schrieb Colomban Wendling:
Le 07/07/2014 18:48, Thomas Martitz a écrit :
[...]
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.
Nice.
Now that the pluxy approach is in the final stages I went onto toying with libpeas.
[...]
There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork.
[...]
If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea.
It's because we require modifications to it for backwards compat, this way we could maintain ABI and API stability across a transition to libpeas. We can drop it from our source after the transition period and/or convince upstream to accept rather geany-specific code (unlikely).
Another issue is that upstream libpeas tends to require recent glib/gtk versions even when not justified. The fork would allow us to lower the glib/gtk requirements.
libpeas is tiny, and is not actively developed (one can consider the project mostly done). So I don't think it's a big deal really. On the other concept of libpeas does provide a lot of benefits so it's worth it IMO.
What alternatives can you propose?
Best regards.