BJörn Lindqvist wrote:
2008/6/2 Johan Dahlin <[EMAIL PROTECTED]>:
An alternative here is make a clean break, eg only use this in new
language bindings and make the typelib/GIR define the API.
For Python I plan to;
* Convert PyGTK .defs to .xml, still keep them locally
* Find out the changes between the .gir in gir-repository/upstream and
apply fixes/patches on top of them
* Write a new module, eg pybank which interacts with the typelibs only
That means that the old cruft we collected in PyGTK will only
be cruft there and not upstream. For future modules we'll use the
more 'dynamic' bindings as available in pybank.
About the xml format... What is the advantage of having the c library
meta data stored in xml format instead of s-expressions? The .defs
files used for Python bindings are very succinct in comparison to the
ugly .xml files GIR brings to the table. Writing and updating
s-expressions is much easier than xml.
There were a couple of reasons to switching to xml over s-expressions.
The primary one is that XML is more popular, most modern languages
have parsers builtin which will make it easier to write tools upon it.
Other reasons includes that xml is more flexible.
The GIR XML is meant to be processed & modified by tools, not human beings.
And presumably, you would still have to hand-write large parts of the
bindings using something analogous to PyGTK's overrides. I can't think
of any automagic that would turn this C function:
void gtk_label_get (GtkLabel *label, char **text);
We solve that by adding annotations in the gtk-doc comment.
The specific case you mentioned will have something like this:
/**
* gtk_label_get
* @label: the label
* @text: (out): the text of the label
*/
Which will in turn be create the following XML snippet:
<parameter name="text" direction="out">
<type name="string"/>
</parameter>
The idea is to annotate most of the available API so almost the complete
bindings can done without manually overriding parts.
Johan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list