Re: [java-gnome-hackers] GSoC Progress Using GObject Introspection in java-gnome
Brought to you by:
afcowie
From: Guillaume M. <res...@gm...> - 2013-08-31 13:19:04
|
Hello, Here is some info about the changes that I have made since the previous email. 2013/8/14 Guillaume Mazoyer <res...@gm...>: > * The GIR files that have been found are passed to the > IntrospectionParser which will parse them and gives Block objects > encapsulated in DefsFile objects like the DefsParser will do. The > DefsFile class may need another name since it is not really DefsFile > now (it is just a Java object representation of what the parser has > found). The GIR parser does not generate DefsFile objects now but returns Block arrays instead it allows to centralize some code in the BindingGenerator class instead of modifying the DefsFile class. Moreover I think that the Block array field of the DefsFile class should not be modifiable. > 1) GObject Introspection data contains a lot of things that we don't > need to know and parse (GRand, GTime, etc… we have well working > corresponding objects in Java). So to avoid them I have created a file > called types.list (see [2]) which contains the list of types that we > care about. What do you think about it? Should we discuss a better > format for such a file? I decided to switch the format of the types.list file to XML since we have all the needed requirements to do so. It is an easy to read and modify file and I have taken the time to make a quick documentation of the XML format to use for this file. > 4) I've chosen to propose some way to override packages names and > types name to match ours these are respectively the > packages-override.properties and the names-override.properties files. > Is it ok for you or should we found a better alternative? The packages-override.properties and the names-override.properties files no longer exist in the last commit. All the information that they used to contain are now located in the types.list file. It avoids to have multiple files to change when adding coverage for a library or doing some changes in the existing ones. > 5) Maybe I will have more questions later :) Yes I do ;) What is the plan to release java-gnome with the GObject Introspection support? I am not a maintainer and I am probably not the right person for this job so I might say some wrong things. I was thinking that we will release java-gnome 4.2.0 to introduce the GObject Introspection based code generator. Of course I need feedback on my code to know if I made the good choices, don't forget that you can easily comment some lines or commit that I have done on GitHub. During the last hangout Andrew and I discussed about merging some part of my 'introspection' branch. I am not sure of what we can merge now. As of today the branch is about 45 commits ahead so if we want to merge some code we probably need to cherry pick. Or maybe we can create a 4.2 branch and merge everything in it and manage 4.1 and 4.2 releases at the same time but it would be probably to hard. Again I am not a maintainer ;). Eventually, I would like to add the coverage for another library. I was thinking about libgweather, or libwebkitgtk or libchamplain. So I propose that you should tell me in what library you are the most interested in. It will help me to also document the process to add the coverage of a library in java-gnome. I would like to write a documentation for this that java-gnome hackers and future contributors can use. Of course we need to validate the work that I have done so far. The GSoC is ending in about 3 or 4 weeks so don't hesitate to give me some feedback, the end will be here pretty soon but I will also continue to contribute to java-gnome after this GSoC ;). -- Guillaume Mazoyer - https://respawner.fr/ |