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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
