The Linux Experiment

It has been a while since I made any mention of my side project CoreGTK. I’m sure many people can relate that with life generally being very busy it is often hard to find time to work on hobby projects like this. Thankfully while that certainly has slowed the pace of development it hasn’t stopped it outright and now I am just about ready to show off the next update for CoreGTK.

First off thank you to everyone who took a look at the previous release. I received quite a few nice comments as well as some excellent feedback and hope to address quite a bit of that here. The feedback plus my own ideas of where I wanted to take the project defined the goal for the next release that I am currently working toward.

Goals for this release:

• Move from GTK+ 2 to GTK+ 3
• Prefer the use of glib data types over boxed OpenStep/Cocoa objects (i.e. gint vs NSNumber)
• Base code generation on GObject Introspection instead of a mix of automated source parsing and manual correction

In order to explain the rationale behind these goals I figured I would address each point in more detail.

Move from GTK+ 2 to GTK+ 3

This one was pretty much a no-brainer. GTK+ 3 is now the current supported widget toolkit and has been since February 2011. Previously my choice to use GTK+ 2 was simply due to the fact that I wanted to make it as cross-platform as possible and at the time of release GTK+ 3 was not supported on Windows. Now that this has changed it only makes sense to continue forward using the current standard.

Additionally this allows for a natural break in compatibility with the previous release of CoreGTK. What that means for the end user is that I currently don’t have any plans on going back and applying any of these new ideas/changes to the old GTK+ 2 version of the code base, instead focusing my time and effort on GTK+ 3.

Prefer the use of glib data types over boxed OpenStep/Cocoa objects (i.e. gint vs NSNumber)

When originally designing CoreGTK I decided to put a stake in the ground and simply always favour OpenStep/Cocoa objects where possible. The hope was that this would allow for easier integration with existing Objective-C code bases. Unfortunately good intentions don’t always work out in the best way. One of the major pieces of feedback I got was to take a less strict approach on this and drop the use of some classes where it makes sense. Specifically keep using NSString instead of C strings but stop using NSNumber in place of primitives like gint (which itself is really just a C int). The net result of this change is far less boilerplate code and faster performance.

So instead of writing this:

/* Sets the border width of the window */
[window setBorderWidth: [NSNumber numberWithInt:10]];

you can now simply write this:

/* Sets the border width of the window */
[window setBorderWidth: 10];

Base code generation on GObject Introspection instead of a mix of automated source parsing and manual correction

The previous version of CoreGTK was, shall we say, hand crafted. I had written some code to parse header files and generate a basic structure for the Objective-C output but there was still quite a bit of manual work involved to clean up this output and make it what it was. Other than the significant investment in time required to make this happen it was also prone to errors and would require starting back at square one with every new release of GTK+. This time around the output is generated using GObject Introspection, specifically by parsing the generated GIR file for that library. Currently, and I must stress that there is still quite a bit of room for improvement, this allows me to generate CoreGTK bindings from scratch within an hour or so. With some of the final touches I have in mind the time required for this should hopefully be down to minutes (the auto-generation itself only takes seconds but it isn’t 100% yet). Better still once this process is perfected it should be relatively easy to adapt it to support other GObject Introspection supported libraries like Pango, Gdk, GStreamer, etc.

So where is this new release?

I am getting closer to showing off this new code but first I have to do a bit of cleanup on it. This hopefully won’t take too much longer and to show you how close I am here is a screenshot of CoreGTK running using GTK+ 3.

This post originally appeared on my personal website here.