Sometimes I write things, sometimes I don't.

To content | To menu | To search

GIR for java-gnome: update week 29

Since we are getting closer to midterm this week was full of work. I have made several changes on the Introspection XML parser to fix a bunch of parsing errors and also to improve some data that the code generator uses (Java packages names for example). To do such a thing I have added the feature to override the name of an Introspection namespace (which will be the Java package name) so the code generator can use a much better package name to generate the bindings layers.

I also have uncommited changes because I need to discuss them to validate my point of view with people from java-gnome. After this first month of Summer of Code, I have realized that java-gnome and GObject Introspection cannot really be friends without some friendship agreements. The idea behind using .defs files for the code generator was to add .defs files and their data only if we wanted to implement the corresponding Java classes and methods for them. So java-gnome has a small number of .defs files with not all the data in them. The idea with the GObject Introspection is different. In the XML files we have all the data (objects, interfaces, enumerations, etc) that we need to generate a complete binding. This is a problem for us.

When we generate the JNI and translation layers in java-gnome we need to have at least a little stub in the public API. This is actually required by the translation layer for the library to compile without any errors. But we don't have public API stubs for everything. We can generate them but is it the right choice? So the idea that I had was to blacklist some of the types and objects that we do not need or do not wish to implement in java-gnome yet (the first types we can think of are GRand and GDateTime for example because we already have the corresponding classes in the Java API. But the blacklist would be very long. I don't know how many percents of the GNOME objects we are covering but we can fairly say that we do not cover 50% of them. So the second idea (which is implemented in the uncommited changes) was to use a whitelist, a whitelist of objects that we want to cover. But this is still not as accurate as the current code generator behavior with .defs files.

I would like to apologize because I don't have any screenshots to show, my work is not related to any user interface it is a deep modification of a library. But here is a little screenshot (which show that I still have a lot of errors) of what I do.



1. On Tuesday 23 July 2013, 09:43 by Rita

Good job, keep posting!