On 13 March 2011 13:36, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 13/03/2011 03:01, Lex Trotman a écrit :
On 13 March 2011 05:39, Matthew Brush matthewbrush@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:
- 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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel