Re: [java-gnome-hackers] Best way to extend java-gnome functionality?

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

Hi,

On Thu, Dec 19, 2013 at 1:06 AM, Niranjan Rao <nh...@gm...> wrote:
>
> I am looking for a recommended/best way to add support for libraries
> which java-gnome currently does not support. My primary interest at this
> time is webkit-gtk version 2 and libsoup and any other supporting
> libraries these two need
>
Sounds interesting, especially webkit which has already been asked for.


> I had a code generator working which will read gnome introspection files
> and will generate required java files and defs files. This approach
> worked well for Webkit version 1. However for Webkit 2, gtk annotations
> are not ready yet.
>
Oh. I did some work during the last GSoC to make GObject Introspection data
usable by the java-gnome code generator. You might be interested by the Git
branch [1]

 My understanding of current architecture is there are finely tuned hand
> written classes which are public - e.g. VPaned which in turn direct
> calls to protected class (GtkVPaned) which do actual work. If I
> introduce new .defs file, I get latter part, but not first part that is
> no public classes.
>
Exactly. The point is to "force" the hacker to write the public API himself
to make it more friendly to developer. It lowers the evolution of the
bindings but it is an important thing to keep the quality and the
consistancy of the API.

Exact problems:
>
You are talking about interesting engineering problems so l'll try to give
my opinion and contribute waiting for Andrew's answer (he's the boss here
:).

 1. Keep my additions as separate as possible if I need to upgrade
> java-gnome library versions.
> 2. Ideally I would like to load only one JNI library. If I can convince
> existing infrastructure to accept new source files while still
> maintaining separation at least at code level.
> 3. Find easy way to generate public classes - at least for bootstrapping
> purposes.
> 4. Convince python script "faster" to accept new libraries - either as a
> command line parameter or as environment variable
>
As you probably know, java-gnome is a big monolithic thing. We discussed
several months ago about how we could introduce optional dependencies in
java-gnome which led to thinking about splitting java-gnome into modules.
This has raised interesting topics (about loading multiple JNI libraries,
multiple JARs, but we'd like to keep one JAR and one JNI lib, well you can
found this in the mailing list archives).
IMHO, the thing that we should do is splitting java-gnome core from the
actual bindings. What does it mean? It consists of separating the bindings
generator code from the bindings themselves. I'd like to see that one day.
In this way people could do their own bindings using the powerful
java-gnome code generator. If someone is willing to talk about this I'm up
for it :)


> 1. Extending code generator so that it can accept source directory on
> command line
>
That could be a solution until we found a more viable one. I am not saying
it is a bad one but I see this as a temporary solution more than a
definitive one. The definitive solution would be the one I have just talked
about ;)


> 2. Adding code generation part which will generate public classes from
> def files. This will give me first cut which can be fine tuned latter if
> need arises.
>
This would violate the current policy about writing the public API by hand.
I am not against generating stubs to spend less time writing them though.

Any ideas/suggestions/thoughts are appreciated.
>
I hope my thoughts were useful.

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

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