I’m giving my second talk at
foss.in this afternoon, Sunday, at 14:00 local. This time it’s a technical one:
(Click through if you care to see the abstract for the talk)
I’ve been working like mad for about 6 months to completely re-engineer the design of the
java-gnome language bindings to GTK and GNOME. Memory management, proxying
GObjects into Java, figuring out how to handle more generic
GValues in property setting. But most importantly, how to create an architecture where we could generate the bulk of the bindings off of
.defs metadata so we can share that with the
pyGTK guys and make our bindings a comprehensive representation of GTK and GNOME without being the totally borked, hand written, leaky, and completely unmaintainable mess that the present
2.x bindings are.
Along the way I’ve been validating the design with code not just code mock ups but a fully working prototype. The most challenging technical piece of late has been designing an new signal handling API. Not only was the API design tough, but the plumbing to make it work is completely voodoo — the
GSignal marshaling APIs are not trivial. Couldn’t have got anywhere without the old
2.x code to use for inspiration, but man oh man it’s been a hard slog.
On Wednesday at 01:48, I finished the last piece of engineering to enable signal connection to work! And so, today, as I’m talking about architecture and working across boundaries between projects, I’m going to be unveiling the prototype and giving the new
4.0 code its first live demonstration.
This is only the beginning. There’s a lot of work yet to come, and I am hopeful that we’ll get the funding we need to make it a reality. Java Libre!
I was talking about all this yesterday over coffee with one of my good friends Sirtaj Singh Kang, who happens to be one of the original KDE developers. After the whole discussion he said “did you know I wrote the old KDE Java bindings? They’re really rickety, and I want to redo them. Do you think I could use this too?”
Wow! Wouldn’t that be something?
Don’t worry. Cats and dogs are not sleeping together: I gather there is already some new Qt Java code floating around, so presumably whoever did that will be extending it to KDE, but no matter. The architecture I’ve developed seems really promising for the task of proxying any underlying native library which more or less follows OO idioms. So as I’m working, I’m keeping in mind that more than just GLib based systems might someday want to use it. Obviously, though, our new code is going to be optimized for the GNOME + GTK case, which is as it should be.