[Geany-devel] GObject, new plugin interface ....
elextr at xxxxx
Sun Mar 13 10:49:54 UTC 2011
On 13 March 2011 17:10, Matthew Brush <matthewbrush at gmail.com> wrote:
> On 03/12/11 19:46, Lex Trotman wrote:
>> On 13 March 2011 13:36, Colomban Wendling<lists.ban at herbesfolles.org>
>>> Agreed. Maybe the easiest way to go would be to write this wrapper
>>> library in Vala, at least as a start point:
>>> 1) it's an OO language, and would save a significant part of the work
>>> needed to write GObject code;
>>> 2) there is a raw wrapper I wrote, with good patches from Matthew 
>>> 3) the amount of work to translate the interface to plain GObject code
>>> would be "relatively" small if needed (though Vala should be OK: it
>>> outputs C code)
>> I don't mind what language is used initially to implement, but I think
>> in the long term it needs to go back to C so as to not increase
>> Geany's dependencies.
> Vala generates a robust C/GObject API from the Vala code, the only
> dependency is for developers who want to recompile the C code from the Vala
> code. I'm not saying it should be done in Vala over C (I'm thinking it) but
> it's important to note that Vala compiles to pure C/GObject. In any case,
> we could mix C and Vala quite easily, using both at the same time, or one or
> the other for specific things, or starting in Vala then changing to C in the
> end, without changing the GObject C API.
I think that Vala can be used so long as it generates C code that can
be included in SVN so that someone who just wants to compile the
latest doesn't need to have Vala available. Similar idea to putting
the geany.html in SVN, even though its a generated file, so you only
need the docutils if you want to change the documentation. You only
need Vala if you are going to change the interface.
>> Reusing some initial work is great, but I would caution that we should
>> think about how the interface should look first.
> I agree, but just to be clear, that's what's been goin on with
> Geany-DBus/Geany-Vala-Binding (picturing how the interface *should*
> look). That's not say we don't need to think about it A LOT more, but at
> least we have some ideas started with those projects.
Ok, I'll have a look and ask dumb questions.
>> Yes, but only if good *language specific* API documentation is
>> generated. It really p@!#$ me off with some (unnamed) C++ wrappers
>> that require you to guess how the underlying C maps to C++ because of
>> lousy (lazy?) documentation.
> If I'm not mistaken, with GObject-introspection, the GTK-DOC gets wrapped up
> in the target bindings, so at a bare minimum, there would be docs for things
> like methods, properties, signals, etc. Of course I'm just assuming the
> GTK-DOC gets put into the target bindings, I've never actually tried to do
> it, and as always, the C API needs good docs :)
My question is does it get adapted to the specific target, if the
Python interface is erm Pythonic, the documentation shouldn't be Cic,
if you see what I mean.
>  https://github.com/codebrainz/geany-dbus
> Matthew Brush (codebrainz)
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel