The tanner’s ugly daughter – or – Musings about a modern GTK+ theming

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+

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.


Aaron Bockover’s complaint about theming in GTK+
Thomas Wood’s comments to GTK+ theming
Documentation of GTK+ theming on
New theming API entry on
GTK+ Theming hackfest announcement
First feedback from the GTK+ Theming Hackfest


14 comments so far

  1. ganton on

    “But there’s one thing almost everyone would agree to: that GTK+ isn’t pretty.”

    I disagree. The Clearlooks theme was the main reason for me as a user to choose GTK+ apps.

  2. captain obvious on

    obviously you are not “almost everyone”

  3. james on

    I think the author is referring to GTK not being pretty from a developer and/or theme developer point of view.

  4. raphael on

    @james: from an application developer’s point of view, GTK+ is actually quite nice. If you like C and don’t mind the boilerplate. But the visual appearance of GTK+ is very limited; there a lot of things you just can’t do. That is one of the reasons why experimental toolkits like Clutter appeared; to fix this gap and make GTK+ nice to look at.

    It’s a totally different perspective if you try to create a theming engine for GTK+. Documentation isn’t GTK+’s greatest advantage. But the theming part is very under-documentated. And you’ll need a ton of hacks to make it look nice with all applications.

  5. Christian Hergert on

    This doesn’t solve the theming problem, but I did make a custom widget to do what you wanted with the buttons and spatial information (aka pill button).

  6. ypnos on

    Thank you for the insights into GTK+ theming. What I am wondering about:

    – Do you have concrete examples of custom widgets so we can understand that problem better?

    – What is the deal about Eugenia’s theme mockup there in the article?

    – How does QT theming, for instance, solve these problems?

    And btw., I use Murrina theming engine and like the look of my GTK+ applications very much. It is pretty to me.

  7. Daniel Kasak on

    It’s nice that development is pushing forward on the theming front, but I have a number of points regarding theming.

    – Firstly, I like the looks of most GTK2 apps vs QT apps. This is one of the reasons my projects ( ) use Gtk2 instead of QT. In particular, I like the ‘aurora’ theme.

    – Secondly, any work done on theming should maintain backward compatibility with Gtk2. Yes, I’m in the camp that opposes a so-called ‘clean break’ and creation of Gtk3. I especially don’t want to see a Gtk3 created *purely* for theming. I have a lot of production code in Gtk2, and I’m not interested in rewriting it for some damned themers. And I don’t think the community is big enough to support Gtk2 and Gtk3 together, which leads to my next point ..

    – Thirdly, there are more important things to do than improve theming. There are a number of bugs I’ve reported, including DATALOSS bugs, in Gtk2. I’ve even submitted patches to a number of these. Sadly, there doesn’t seem to be enough manpower to even review these patches. Again, we’re talking about DATALOSS bugs. I’d rather see this junk sorted out before the eye-candy stuff is started on. Seriously.

    If all these issues are address, by all means, go crazy with theming improvements. But for people who really want to break with the old Gtk and get some real eye candy, why not use EWL, ETK or Elementary from the Enlightenment team. They know how to produce eye candy. And frankly, I’m starting to think the Enlightenment dev community is bigger than the Gtk dev community. They’ve got *three* widget toolkits based on Evas. Yeah maybe that’s too many. But no-one can accuse them of being inactive.

  8. vm on

    BTW about desin. The gradient background of this page doesn’t help to read. Looks sweet, usability sucks.

  9. damaged justice on

    There is very little objective reality when it comes to subjective aesthetics.

    In over twenty-five years of computing, I have yet to see a user interface I would describe as “pretty”.

    Somehow, I survive.

  10. Richi Plana on

    I wouldn’t readily agree that Gtk+ isn’t pretty, but it certainly isn’t flexible. It doesn’t allow for creative and ingenuous people to design interfaces that suit their various objectives.

    I have to agree with the author’s explanation for this, though. Software developers aren’t the best UI designers. The sad thing is, the two groups should work hand-in-hand, where interface designers are clients of software devs who have their requirements and software developers and designers strive to suffice these requirements.

    I belong more to the software developer camp and I can already see developers thinking (with their narrow view of things) how eye candy can’t contribute to productivity or ease-of-use. Worse, more features usually mean a hit on software performance. (This is akin to console-only users who think that everything is much better on console compared to GUI apps).

    This isn’t true, though, as evidenced in designs from companies like Apple. The important thing is for information and opinions to flow freely and for people to have the openmindedness to at least consider the possibility that there are better ideas out there than their own.

    Can’t wait to hear the results from Hackfest.

  11. damaged justice on

    This is akin to console-only users who think that everything is much better on console compared to GUI apps

    For me, and my purposes, this is true.

    “Better” means nothing until you state: Better for whom, and for what purpose?

  12. Top Posts « on

    […] The tanner’s ugly daughter – or – Musings about a modern GTK+ theming GTK+ may be called many things. I would call it ’simple’ and sometimes even ‘elegant’, […] […]

  13. bolicovici on

    I want: Functional, Easy to use, Intuitive, Consistent

    It can be ugly as long as the issues stated above apply

  14. […] The tanner’s ugly daughter – or – Musings about a modern GTK+ theming […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: