On Sat, 30 Apr 2011 00:24:10 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 04/29/11 10:12, Nick Treleaven wrote:
On Thu, 28 Apr 2011 09:01:08 +0200 Frank Lanitzfrank@frank.uvena.de wrote:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we
BTW Colomban started work on Vala bindings without changing the plugin API: http://gitorious.org/geany-vala-binding
This has been discussed quite a bit in the thread: http://permalink.gmane.org/gmane.editors.geany.devel/4138
Thanks for the link.
Just to add my point of view:
- I think this would be very disruptive to both Geany's core and
existing plugins. I also really don't like GObject code in C.
So the GObject code could be written in Vala, solving that issue.
*VERY* disruptive as noted in the thread, if the core code was modified directly. Regarding preference for GObject, my only thought is that the plugin API should consider the user of the API rather than the developer writing the API, unlike in the rest of the core code where it doesn't matter to the user and more to the developers. In geany-plugins there is already at least a few plugins which are using GObject C code despite the current API and IIUC, there would basically be only 1 "mandatory" GObject class to use a GObject API, the rest of the code could be written however.
It just seems like a lot of work. Vala is quite high level, I have to wonder whether all the disruption is worth it.
- Would it actually work? Geany is not a shared library, so this
might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made).
The idea previously discussed, IIRC, is to make a separate shared library and also a separate plugin loader, being loaded (for the time being) as a proper/regular Geany plugin, to minimize the impact to the core code. I'm pretty sure it would work, but with the current setup it's just too much trouble (see GeanyPy).
Ok. Thanks for explaining. Both current setup and the new approach would need plugins to be able to contain multiple other plugins, in order to support a dynamic language.
Regards, Nick