[Geany-devel] GObject, new plugin interface .... & Vala bindings

Matthew Brush mbrush at xxxxx
Sat Apr 30 07:24:10 UTC 2011

On 04/29/11 10:12, Nick Treleaven wrote:
> On Thu, 28 Apr 2011 09:01:08 +0200
> Frank Lanitz<frank at 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:

> I think this is great. It might be doable to maintain this with Geany's
> API when ready. This would be a big leap forward for plugin writers,
> and little/no impact on the existing API.

I've written/started a few plugins with it so far, for example 
geany-multiterm, geany-dbus previously mentioned in the thread, and a 
few others, and it's quite nice, although not very "Vala-like" since it 
directly wraps the existing non-(G)Object API.

>> What's the outcome here? I saw a lot of technical discussion followed up
>> by my original posting but nobody took over the rule to bring all the
>> idea into synch. Not sure whether I might did miss something.
> Just to add my point of view:
> 1. 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.

*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.

> 2. 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).

Matthew Brush

More information about the Devel mailing list