Sometimes I write things, sometimes I don't.

To content | To menu | To search

GIR for java-gnome: update week 31

The status update of my work is a little late this time due to some personal issues I had this week end.

The work is mostly the same as during week 30. The XML parser needs improvements a lot I found improvements to make every day. So now the parser can handle Union types, the special methods like "free" and "copy". I also had to tweak the public API of java-gnome due to some changes introduced by the use of Introspection data (some variables to delete because they do not exist anymore for example). Since we will probably do a major release when the Introspection based code generator will work I guess that all the public API changes will not be a problem.

The other part of my work consisted in trying to make the Introspection parser more maintainable. It has grown a lot since the beginning of this GSoC and sadly it has become less and less readable and maintainable due to copy/paste of code blocks etc… Currently, the Introspection parser only is composed of about 1800 lines. To compare, the .defs files parser is composed of about 390 lines so there is a big difference. I moved some lines of code into static methods so they can be used more easily and be more maintainable.

The code of the XML parser is starting to get stable because it works in most of the cases. I still have to investigate about 250 compilations errors when building java-gnome (errors produced by the files that the code generator writes). A lot of errors are due to the way the .defs files were written before so they should be fix in the following weeks.

I had to do some black magic to bypass some problems with GList and GSList parameters or return types and also with parameters where the name was specified but not the real type. I do not know if it is something generated on purpose when building the Introspection data or if it is a bug but it happens sometimes. Lets take an example. A common seen XML description of a parameter in a .gir file looks like this:

<parameter name="pixbuf" transfer-ownership="none" allow-none="1">
 <doc xml:whitespace="preserve">a #GdkPixbuf, or %NULL</doc>
 <type name="GdkPixbuf.Pixbuf" c:type="GdkPixbuf*"/>

But sometimes we can found this:

<parameter name="pixbuf" transfer-ownership="none" allow-none="1">
 <doc xml:whitespace="preserve">a #GdkPixbuf, or %NULL</doc>
 <type name="GdkPixbuf.Pixbuf"/>

So this is a tricky part because of several things:

  • The code generator can not handle a type like GdkPixbuf.Pixbuf it actually needs GdkPixbuf.
  • How can we know if it just a GdkPixbuf or a GdkPixbuf* ?
  • If we have just EventType how can we know what namespace owns EventType (Gdk, Gtk, ...)?
So here is the black magic. Can we make thing uglier? :(

A meeting with Serkan Kaba (my mentor) and Andrew Cowie (java-gnome's maintainer) has been set up to discuss about my progress and to make some technical choices to decide what path we should take.

During this week (week 32) and the following I will try to implement a way to override Introspection information so we can control the behavior of the code generator like we can when using the .defs files.


1. On Thursday 8 August 2013, 11:14 by Colin Walters

There are two kinds of names here:

"GIName"s are Namespace.Name. These are what the dynamic bindings consume. When you see just e.g. Pixbuf, that's a shorthand for <currentnamespace>.Pixbuf, which is GdkPixbuf.Pixbuf.

I know that you guys are using the c:type for code generation, which complicates things as you need to work in both worlds.

Now when you see a parameter with no c:type, that's most often signals. There *is no* representation in C of the declaration, so that's why the scanner didn't output a c:type. You should just synthesize it. as <namespace>.<name>.

If you have more questions, ask on please!

2. On Thursday 8 August 2013, 11:34 by stuaxo

I wonder if it's worth fixing the upstream XML files in these harder cases, if they don't have enough info ?

3. On Thursday 8 August 2013, 12:41 by Guillaume

@stuaxo I actually don't really know how they are generated and how all the information are taken from the source code. I don't know if it generates such XML data on purpose or not. Maybe I should have a talk with the Introspection specialist to know more about this.