java-gnome-hackers

[java-gnome-hackers] GSoC Progress Using GObject Introspection in java-gnome

[Guillaume M. <res...@gm...>]

Hello,

After a Google Hangout with Andrew (AfC) we have noticed that I have
not write anything on this list since the beginning of the GSoC. So
here is a mail that should fix this and it is a chance to get more
people involved.

1) A link[1] where you can find the branch that I am working on.

2) Serkan and I chose to use the XML data generated by the libraries
to work with. Why? XML is simple enough to parse in Java (and a lot of
API can be used, I've chosen XOM for us) and it is readable by human
being to investigating a XML manually is easy enough to debug our new
parser.

3) How GIR works in java-gnome for now?
    * A new configure step has been added to check if the GIR files
exist on the system. It tries to look for several files in a given
directory for each distros (for now only Debian and its derivatives
are supported [because I use it]) so you are welcome to give me
patches to add support for your distros.
    * The branch introduces a new parser for the code generator called
IntrospectionParser
    * 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).
    * After the Introspection data parsing, a second parsing is
performed using .defs files located in src/overriders. These files can
be used to provide data to override GIR data or to add data libraries
coverage that don't provide GIR data. So basically it is the "old"
DefsParser that does the work so we can still take advantage of it and
still use .defs files if we need to.
    * After all of this the code generator can still work like it does
for years. So I've really worked on a new parser. It is getting usable
and from today [14th August 2013] java-gnome actually compiles while
using GIR data :).

So this work is in a good way to bring GObject Introspection in java-gnome soon.
We still have choices to make and this is the second part of this mail.

Andrew, Serkan, and everyone is welcome to participate of course, here
are some questions that we need to answer:

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?

2) Some functions, methods and other things are marked as deprecated
in the GIR data, what should we do with them?

3) Should we consider renaming the DefsFile class to something more
relevant starting from now?

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?

5) Maybe I will have more questions later :)

Thanks for your future help.

Hope you are enjoying the work that I have done so far.

[1] https://github.com/respawner/java-gnome/tree/introspection
[2] https://github.com/respawner/java-gnome/commit/c3c772e14ce31c3c6d986e5d4406134e69d93d53

-- 
Guillaume Mazoyer - https://respawner.fr/

Re: [java-gnome-hackers] GSoC Progress Using GObject Introspection in java-gnome

[Guillaume M. <res...@gm...>]

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/