GTK+ may be called many things. I would call it ‘simple’ and sometimes even ‘elegant’, referring to it’s foundation of pure, elegant C. But not everyone is compelled to use those terms, using terms like ‘clumsy’ and ‘unwieldy’ instead. Yes, there is a lot disagreement. But there’s one thing almost everyone would agree to: that GTK+ isn’t pretty.

Well, it is true. But why? Well, it seems that programmers and hackers don’t make good designers. But that’s not the whole story. Another reason is the current GTK+ theming. There are some things which just are not possible.
From a ‘old school’ programmer’s point of view GTK+ works nicely. It has all the widgets one needs to create decent and functional application. You can stick them together and the GUI you’ll get will work nicely. But the look of GTK+ has never been breathtaking and, to be honest, GKT+ is not as flexible as it could be. Animation is difficult and the layout of GTK+ applications tends to be very static.
In the last few years this weakness has gotten more apparent as other toolkits advanced more and more in the terms of eye-candyness: HTML/JS is highly flexible for creating innovative GUIs as the plethora of usable and unusable websites demonstrate. Qt provides a broad and deep platform which demonstrated its capabilities with KDE 4. If GTK+ wants to stay competitive, it needs to catch up. In other words; GTK+ theming is stuck and needs serious overhaul.

To understand the reasons, let’s first take a look at the current architecture of the GTK+ theming.

Focus lines are not possible in GTK+

GTK+ theming as of now

The look of GTK+, just as with all modern graphic tool kits, is defined by themes. Theming in GTK+ consist of three parts: Engines, Styles and Configuration. All in all it can be summarised as: “Themes provide styles, which can be configured and assigned to widgets”. But let’s start at the beginning.

GTK+ provides a set of drawing primitives: lines, boxes, arrows, and so on. Whenever a widget is drawn, these drawing primitives are used. The implementation provided by GTK+ is very basic and not very sophisticated, but it can be overridden.

That is where the theming engines come into the picture. The theming engines provide their own implementation of those primitives. You can even add additional configuration parameters. These are called ‘Styles’. Say, you don’t just want a foreground and background colour for your widget. Say you want a gradient? Easy, just add a configuration parameter for that style and tell the engine where to use gradients. This happens in the ‘.gtkrc’ file where every widget is provided with a set of configuration parameters.

But that only allows you to style the individual primitives. It is not possible to change the geometry of a widget. Say, for example, you want round edges for your buttons? Well, the only way to do that is to hardcode this into the theming engine; whenever a button is drawn, just handle this in a special case. Query the widget ancestry and draw your round-edged button whenever needed. Problem fixed!

The drawbacks

… as long as you don’t want custom widgets. Drawing custom widgets can be a major pain with GTK+. You can draw custom widgets, GTK+ is perfectly capable of doing that. There are some major GKT+ application which provide their own widget implementations because the default GTK+ implementation didn’t suite their needs. The problem arises as soon as you want to mimic the look a certain kind of widget. Then you’ll run into problems.

You see; styles are hierarchical. You cannot draw a ‘button’ style if you don’t derive from GtkButton. You have no way to tell the theming engine to draw your widget like a button. So the only thing you could do is to use the drawing primitives to draw something that at least resembles a button in most themes. But as you may have guessed; this is a very difficult task and not very funny.

Knowing about this problem, some theme engine developers have taken special care that some of the more popular applications get drawn as intended; they include special clauses to check for some known custom widgets. But that only makes matters worse, for you cannot know every custom widgets. So user interface design with GTK+ in the last few years has effectively been a choice between using only GTK+ widgets or having custom widgets look either crappy or out of place.

GTK+ also makes it particularly difficult for themes to draw widgets spatial dependant. Suppose you want three buttons to be drawn, side by side with the outer edges of the first and third buttons lightly rounded? Well, currently it is not possible; the theme engines are lacking spatial information and the application developers have no way to tell a theming engine when and how to treat a widget in a special manner. Well, that’s not completly true; there is a way to pass ‘details’ to theming engines. But the nature and definition of those details has apparently never been documented and got lost in space and time.

To make matters worse, theming isn’t isolated. It touches many other issues, like animation, layouting of widgets (which is nowadays fixed for most applications) and also platform integration.

The silver lining on the horizon

These drawbacks of the GTK+ theming architecture, the basic design, goes back to the very beginnings of GTK+. There were some changes to the theming system during the last major version bump (1.2 to 2.0), but it has stayed always stayed the same, more or less. And people noticed. Now some GTK+ developers organised a meeting about the future theming of GTK+, lovingly called ‘Hackfest’. And their plans are impressive; to provide the basic architecture of a future GTK+ theming and rendering infrastructure. This wouldn’t be half as spectacular if only GTK+ developers were invited. But if you take a look at the schedule, you’ll see that Qt and Mozilla developers are also participating. If this results in an easier integration of third party applications into GTK+ and thus the GNOME desktop will remain to be seen, but it certainly looks promising. Having Mozilla/Firefox and Qt applications look /exacly/ the same as GTK+ applications might finally be possible.

The ‘hackfest’ has been going on since Monday and the first results are already spilling out. The new theming API, it seems, will focus on Cairo and and CSS. Now Qt has had CSS-style theming for quite a while and interoperability on that layer suddenly seems possible. Maybe we’ll even get a unified theming configuration language for GTK+ and Qt! I’m quite curious how they bring all these pieces together; theming, layout, animation, integration and odd-shaped widgets. But let’s wait and see.

In the last few weeks I’ve been playing around with Vala, and enjoying it. “What the heck is Vala”, you might ask, and of course you will get an explanation. Not only because Vala, though still in its infancy, hasn’t gotten the attention it deserves.

Vala is, in some sense, a new programming language. It’s syntax and structure leans heavily towards C#. As Jürg Billeter, the mastermind behind Vala, likes to put it; Vala is an amalgam of different C inspired languages, mostly C++ and C#. An though there is no mercury in this mixture, you’ll find many a gold nugget in Vala.

“Why another programming language? Aren’t there enough out there yet?” might be your next question. And of course this also deserves an explanation. Yes, there is an awful lot of programming languages out there. But what makes Vala special is it’s unique combination of high-level programming and low-level interface. You see; even though Vala supports modern programming language features like objects, foreach-loops, generics, annotations, memory management and exception handling, Vala is very slim. It doesn’t require a virtual machine. Indeed; Vala compiles are binary compatible to C. You can use C libraries from within Vala, you can even use Vala libraries from C. That’s because Vala, at it’s core, still builds upon the foundations of C. But more on that later. First, let’s take a look at a piece of Vala code.

Well, that does look familiar, doesn’t it? All control structures (for-loop, while-loop, switch/case, if/else, …) behave like their C counterparts. Vala is very much like C, although there are some peculiarities. Like that string-datatype, and that stdout-whatsit.

Having stored this piece of code in a file called hello0.vala, it can be compiled:

valac hello0.vala

No rocket science thus far. The resulting binary can be executed and will result in following output:

$./hello0
Hello, World!

Now that we have made ourselves a little bit comfortable with the Vala tool chain, let’s take a look at some of the more interesting features Vala has to offer. That string data type, for example.
In our main function, we’ve defined a single input parameter. string[] argv; an array of strings. But other than simple C arrays, this is not only a block of continuous memory. It’s an object by itself and thus has properties we can inspect. It’s length, for example.

This little example already shows some features of Vala. Obviously there are classes, with members and methods. But this example isn’t very sophisticated. Let’s try something more interesting. For example, let’s replace those booleans with a bitmap, bring in some generics and inheritance.

As you can see, Vala supports all features you’d expect from a modern programming language. Classes, abstract classes, inheritance, generics, method overloading and so on. And still there are many features I didn’t touch in this essay, like interfaces, signals, exceptions, namespaces, access level modifiers, lambda functions and packages. And most important; Vala provides memory management, freeing the developers of most the hassles usually associated with low-level application programming.

So with all those fancy features, how can Vala still be compatible to C? It’s because valac, the Vala compiler, uses the GLib type system for its underlying framework; Vala code is translated to plain C code with hooks to GLib and (if one uses GLib.Object as superclass) GObject. This generated code in turn is compiled by GCC. Vala applications thus are native binaries, requiring neither an interpreter nor a virtual machine.

Vala provides (very) complete mappings to many important Unix C libraries, such as stdlib, D-Bus, Cairo, SDL, Poppler. And of course, with its roots deep in GLib, Vala also supports the Gtk+ framework and all related libraries. The excellent libgee, also developed in Vala, provides array lists, hashes, sets and collections. Use of the pkg-config system makes using libraries very easy. And as soon as GObject introspection is in place, bindings to all kinds of scripting languages come with the package for free.

Vala, now at version 0.3.4, is still under heavy development. My first experiments have already uncovered some bugs, which got fixed immediately. Vala might still need some time to come of age, but already it is picking up momentum, as the first projects start to use it. Especially developers with an aversion towards C++ might find Vala interesting, for it links the solid GLib type and event system with an elegant syntax, providing all the necessary tools for rapid application development on a stable foundation.