Sometimes I write things, sometimes I don't.

To content | To menu | To search

GIR for java-gnome: update week 33

I am glad to say that I am ahead of my schedule. The GSoC will still continue for approximately a month but I have already reached the goal that I was supposed to reach in 2 weeks. So I am happy to say that since this commit java-gnome compiles and passes the tests suite with the Introspection based code generator. There is still work to do though. So the plan is to focus on the code polishing and the documentation of the new code generator behavior. I have written a mail on the java-gnome hackers mailing list to inform and summarize my work to the contributors. There are also several questions that still need answer to make sure that everyone will be happy with the new code generator.

I have done a quick graph to show how the code generator works in my java-gnome Introspection branch.

As we can see the data that feed the code generator come from 2 sources. The first and main source is the GIR data and the second source is the DEFS data. We are using DEFS data for several years in java-gnome and they are now an optional source of data because GIR is meant to replace DEFS. Why did I choose to keep .defs files? To be able to add coverage for libraries that do not provide GIR data yet or to override methods, functions and signals. In this way we can combine the accuracy of GIR data with the power of the .defs parser. Some people might be confused when viewing the DefsFile[] structure in the middle of the graph. This is not a step that says that we are writing .defs files from GIR data. DefsFile is actually a class that represents what we parsed before. Until the Introspection it was only DEFS data but now I guess that this class needs a better name.

Here is a list of what I have done during the week 33:
  • Handling of GError** parameters when functions throw error.
  • Providing a new way to whitelist types and blacklist methods, functions and signals.
  • Cleanup some part of the code.
  • Add several special cases where constructors and methods needed to be overridden.
  • Fix some unit tests.
  • Fix the parsing of enumerations.
  • Fix some memory management issues due to constructor return value owner problem.
Things are now getting stable, the goal to the end of this GSoC is to polish the code, write some documentation, take some decisions to validate or invalidate some design choices, add the coverage of another library (WebKitGTK+ maybe, if you have an idea feel free to tell me) and in the future, release java-gnome 4.2.0 with a fully Introspection based bindings!