The Old Way:

1. Developer in libfoo (a C library) works on solving a problem, decides to create foo_bar() function
2. Function foo_bar works, and is committed
3. A period of time later, a new shared library appears in OS update package
4. You install the package
5. You try to use function bar from your favorite $LANGUAGE bindings, but it isn’t bound yet
6. You curse and go searching bugzilla to see what the status is
7. If upstream is active, some manual review is done to make sure the function is sanely callable from $LANGUAGE
8. If the function has some special requirements, sometimes metadata is manually added to hackish .defs files
9. A patch is eventually made and committed
10. Another period of time later, new bindings appear
11. You can call foo.bar()

Note that steps 7,8, and 9 have to be repeated for each binding, be that PyGTK, Gtk#, java-gnome, etc. Even worse they all have divergent .defs files.

The New Shiny Future Way:

1. Developer in libfoo (a C library) works on solving a problem, decides to create foo_bar() function
2. If it is not sanely bindable, author gets warning from g-ir-scanner, reworks it or adds metadata, commits
3. A period of time later, a new shared library appears in OS update package
4. You install the package
5. You can call g.foo, because your $LANGUAGE bindings use GObject-Introspection

The new way, obviously, is going to be significantly better. By actually including all the metadata necessary to interface with the system in the shared library (.so) itself, we eliminate a large lag time before improvements in the lower levels of the stack become usable to bindings. Even more important I think is that by integrating into the build process of the GObject-based C libraries, we can help ensure that authors don’t add new interfaces that are difficult to bind.

Why am I talking about this? Well, I just reached a major milestone in a side project I’ve been working on. Here’s a screenshot:

Instant GObject/WebKit bindings for the JVM

And not just WebKit of course – this is a large step forward for Java bindings for Gtk, Clutter, libnotify, libgypsy, various canvases like hippo canvas and in general the entire “Free desktop stack”.

Of course because it’s Java, it’s also instant bindings for Jython, Rhino, JRuby, Groovy, etc. Just ran this program with Jython trunk:

from org.gnome.gir.dynamic.WebKit import *
from org.gnome.gir.dynamic.Gtk import *
from org.gnome.gir.gobject import *

GObjectGlobals.init()
GtkGlobals.initCheck(None, None)
win = Window(WindowType.TOPLEVEL);
sw = ScrolledWindow(None, None)
win.add(sw)
wv = WebView()
wv.open("http://www.gnome.org")
sw.add(wv)
win.setSizeRequest(640, 480)
win.showAll();
GtkGlobals.main();

I just tossed up a web page for the project here. Right now it’s basically blocked on finishing gobject-introspection itself; finishing the .gir to .repo compiler. So I’ll be looking at that. My personal goal was to get bindings for some canvas (probably hippo), and clutter, along with all of Gtk+.

Let’s take a step back though. What I think is interesting about this is that it enables much more seamless multiple layer applications. I blogged about this before. At the bottom, you have unmanaged C (GObject) code. In the middle, you have a managed, statically typed core (Java/.NET). At the top, you have a managed, dynamic language (Groovy,Boo,Python,JavaScript). GObject-introspection dramatically lowers the pain for going between the bottom and middle layers. Using the JVM (or .NET) makes the middle and top layer transition much nicer, especially for a runtime-native language.

Realistically landing and finishing all of this is probably a year out at the earliest still. But it’s fun to hack on!

Edit: By the way, HotSSH version 0.2.5 is out, and this one actually has a README that tells you how to install it! It fixes various bugs, and most interesting it has the favicon work.