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

[Lex Trotman]

On 13 March 2011 13:36, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> Le 13/03/2011 03:01, Lex Trotman a écrit :
>> On 13 March 2011 05:39, Matthew Brush <matthewbrush at gmail.com> wrote:
>>> [...]
>>>
>>> If there was someone with lots of GObject experience that would be willing
>>> to review my code on a regular basis, I'm willing to volunteer my time and
>>> do most of the coding (or at least my share, depending who else is
>>> interested in working on this).
>>
>> [...]
>>
>> I would suggest that the GObject interface needs to be designed to
>> work right for the plugin developer languages and then mapped over the
>> current internal implementation.  I'm not totally convinced that the
>> current implementation is the best way to present things to plugins,
>> although after some discussion it may be the best way to go.  This
>> might not be very efficient initially but it allows testing of the
>> interface without disrupting core too much.  Then over time other
>> changes could be made.
>
> 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 [1][2]
> 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.

Reusing some initial work is great, but I would caution that we should
think about how the interface should look first.

>
>> This will also help to allay some of Franks fear of the size of the change.
>>
>> I would suggest that the interface needs to support one static
>> compiled language, Vala? and one interpreted dynamic language Python?
>

I should have said I suggest using one static and one dynamic one
during development, I wasn't intending to suggest they be the only
ones in the long term.  But my experience is that it is important to
try both because it is easy to tailor the way the interface works to
one paradigm only and make the other harder to implement or
spectacularly less efficient.

> They are good targets IMO, but I also think it would be good to support
> more languages if possible. GObject-Introspection, if done right, can
> provide good-quality binding for a plenty of languages almost for free
> (C++, Python, JavaScript and many more).
> Normally the GI bindings for the target language takes care of
> translating between conventions -- for example, a Python programer would
> like to use obj.foo_bar() and a JavaScript one better obj.fooBar().
>

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.

Cheers
Lex

>
> However, even though I like the idea of creating this new plugin API
> supporting other languages, I will not tell I'll help a lot because I'm
> really not sure of the amount of time I could spend on it. However, I'd
> be happy to help from time to time, when I can :)
>
>
> Just my 2¢,
> Colomban
>
> [1] http://gitorious.org/geany-vala-binding/
> [2] though we started to try to make it a more Vala-style API, I doubt
> we could succeed without a wrapper library. Maybe the work Matthew did
> on GeanyDBus might be a start
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>