[Geany-devel] GObject, new plugin interface ....

[Colomban Wendling]

Le 17/03/2011 09:17, Lex Trotman a écrit :
> On 17 March 2011 17:56, Matthew Brush <mbrush at codebrainz.ca> wrote:
>> Unfortunately, there is some context around this which has been discussed
>> around the geany-vala-binding, that a lot of which wasn't on a ML.  It's
>> very easy to summarize some of the ideas I've had/heard so far:
>>
>>  - The geany-vala-binding should be sort of a "raw" wrapper around
>>    the existing plugin API, providing simple access from Vala code.
> 
> Not sure about wrapping the existing plugin interface, see below

As Matthew said, this can be useful to write the end-user wrapper
without bothering to write the bridge code. The current Vala binding is
more or less a 1:1 mapping of the current C API, but can easily be used
to write the high-level binding we talk about. Avoids the need of [CCode
..] ;)

>>  - There needs to be a GObject wrapper around a lot of the
>>    existing stuff where it makes sense, since a lot of it is
>>    sorta OOP in design.  This could use Vala to generate all of
>>    necessary boiler-plate GObject C code and allow doing things
>>    like ABCs and interfaces without gobs of (hand-written) code.
> 
> Well anything to avoid writing GObject code in C has my vote :-).  My
> only comment is that my (limited) look at the Vala docs seems to be
> lacking in documenting how to wrap existing C interfaces that don't
> introspect properly. Eg  I couldn't find what goes in [CCode...].
> Might be just my searching of course :-)

Se above ;)
But basically you're right: Vala doc on this side is a bit missing.

>>  - Signals for the plugins need to be emitted from the
>>    appropriate objects. rather than the current central
>>    GeanyGObject which is has all the signals.  An example would
>>    be that the "saved" signal should be on a Document object.
> 
> Totally agree, but this is where using the existing plugin interface
> is deficient, very few signals are provided.  But core will have to be
> changed to emit more.  I don't really see that as a problem, adding
> emits in appropriate places should be no problem, but it does imply
> that then core can see the GObjects so it can emit on them, again I
> don't think the existing plugin interface provides much support for
> making things in the plugin visible to core.  Also when to create and
> delete the GObjects.

Why? The current API has all its signals in GeanyObject, and it works
fine so far.
And wrapping signals correctly is "only" a matter of connecting to the
GeanyObject signal and emit another back when you received the
GanyObject one. Sorta:

  geany_object.signal_name.connect(() => this.signal_name.emit())

or whatever fits.

Or are you referring to something else? (maybe I miss something :/)

>>  - Libpeas[2] should be used as the actual plugin finder/loader.  It's
>>    a GObject/GLib library designed specifically for finding plugins
>>    in different languages, loading their interpreter, and doing
>>    stuff like activation/deactivation.  It seems Gedit is using this
>>    as well as several other popular GNOME-ish programs.
> 
> Looks like it might be helpful, how easy it might be to get it to work
> alongside the existing plugin manager (so we get one UI) I don't know.
>  Remember we don't want to chop existing plugins off.

Should be possible (and quite easy) as far as one have access to the
plugin dialog internals. Peas has separated UI and core, so it should be
possible to build your own UI.

>>> Having reviewed what has been said in the thread to date, there is no
>>> real substance, so I think its likely that we may be talking about
>>> subtly different things.  So to start the ball rolling here is an
>>> initial description of what I understand as the aims of this work and
>>> how I see it possibly being implemented.
>>>
>>> As I see it the purpose is to define a new plugin interface to Geany
>>> that exposes all the required machinery through a set of GObjects
>>> which can be (semi) automatically interfaced to languages other than
>>> C, allowing Geany to have plugins written in multiple languages.
>>
>> Using GObject-introspection hopefully in most places[4].
> 
> The issue with that IIUC the stable version will be for GTK-3 and
> since Geany still supports GTK 2.8 its got a *way* to go before it
> gets to 3 :-)

GObject-introspection is part of GObject AFAIK, and GObject hasn't moved
to 3.0. So I guess there is no problem on this side ;)

>>> I see the GObjects as simply containing pointers to one or more of the
>>> Geany structures and the methods each being just a few calls to
>>> existing functions that operate on these structures.
>>
>> Yep, and wrapping them up in GObject properties and signals so Gobject
>> introspection can do its magic in making the higher level language bindings
>> idiomatic (or I guess OOP-ish, since it's roughly the same in most languages
>> I know).
> 
> Well getters and setters rather than properties, IIUC GTK is heading
> towards hiding properties or at least making them read-only.

Nope, GTK tries to remove all public *fields*, not properties. The fact
GTK has almost getters and/or setters for each property is more for
being convenient from C code, where getting a property is generally
harder than in other languages.
In languages having properties, the properties are better IMHO.

>>> There will still need to be code added to the existing implementation
>>> since it needs to create and destroy the GObjects as required and will
>>> have to emit signals on them when required.  But this is a much less
>>
>> My initial though was a regular old Geany plugin, using the Vala binding and
>> Vala output C API to provide the "glue" without even touching the existing
>> core code directly.  This would at least provide a nice testbed.  Then the
>> existing plugin API could just have the odd struct tweaked or function
>> added, etc.
> 
> As I said above, I think we will quickly find that this isn't enough.

Maybe true.

> Also just how well does Vala operate through the indirect pointer to
> function interface provided by the current plugin interface?

Basically: as well as C. Vala translates to C code, then as far as the
result C code works, Vala will work, and since the plugin API hides the
indirect pointer complexity, even the binding wouldn't see it.


Cheers,
Colomban