Archive for the ‘software’ Tag
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.
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!
… 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 http://live.gnome.org
New theming API entry on http://live.gnome.org
GTK+ Theming hackfest announcement
First feedback from the GTK+ Theming Hackfest
GTK+ has come a long way. From its humble beginnings as “The GIMP ToolKit”, it is now used in a plethora of applications. In fact, GTK+ is very popular. GNOME, one of the leading desktop environment on Unix systems, uses GTK+ almost exclusively. The Gimp is built upon GTK+, of course. And there are many commercial software developers like Adobe, NVidia and VMware that decided to use it as a base for their products.
Still, there are several shortcomings with GTK+. Development of the 2.x series started back in 2002. Since then, GTK+ has ripened and aged. It has aged well, but still: its age shows. Throughout the 2.x cycle, several years now, the developers have kept GTK+ ABI compatible. This keeps application developers depending on GTK+ very happy: they can be sure that code linked to an older version of GTK+ continues to work with newer releases. Packages released back in 2002 will continue to work with new library releases. That’s great, because no third-party application developer likes to rebuild and repackage the whole product line, just because a new version of the underlying libraries got released and all the distribution start packaging that version. It causes work and trouble. And for commercial/proprietary developers that means costs.
The commitment not to break ABI made a lot of people very happy. But it also put very tight constraints on the GTK+ developers. It’s not that easy to add new features and remain ABI compatible. Minor features, yes. But as soon as you want to make radical improvements and need to change the exposed data structures, you run into serious trouble. It just not possible beyond a certain point.
On the 2008 GTK+ Hackfest in Berlin, Imendio’s GTK+ hackers presented their vision  of GTK+’s future and the reasons why they think that GTK+ has to make a step forward, embrace change and break ABI compatibility. Other GTK+ developers  have also voiced their opinions, listing parts of GTK+ that need serious love, but state that they don’t require breakage.
Whether or not these are the things that will mark the road to GTK+ 3.0, almost all of them need attention. And give hints to the shape of things to come.
Theming is one major aspect of GTK+ that needs a serious overhaul. Theming in GTK+ sucks and blows big time. The initial concept of how theming works in GTK+ stems from the very first releases and never received serious love. As a result it is very difficult to do fancy graphic things in GTK+ or to make custom widgets that fit into the rest of the desktop. The funny look of Evolution’s tree headers in some themes is one symptom, but every developer with the need to write custom widgets is looking for a hard time.
There have been several suggestions on how to do that, some of them involving CSS-style theming . CSS would be nice, for sure. But even the ability to paint one widget to mimick another would be a huge gain. Application-specific theming and custom layouts? Delicious.
Although it is possible to create animations in plain GTK+, it’s not very easy to do. Out of the desire to create fancy interfaces in the image of the iPhone interface arose several GLib/GTK+ inspired libraries; Clutter, Pigment and Moonlight. All of those have drawbacks, however: Clutter doesn’t use the GLib event system, Moonlight is written in C++ (a no-go for a GTK+ library) and Pigment is in a very rough state. Still, there are very solid plans to what extent a scene-graph library might interact with GTK+ and what requirements such a library has to fulfill .
GTK+ has no standard Canvas. There is a GnomeCanvas, but it’s deprecated, not very popular and lacks some key features, like drawing GUI. Many developers resort to plain Cairo when it comes to custom graphics, but Cairo is lacking a way to draw GUI elements also. Nothing gained. There are some possible candidates  for a possible GTKCanvas, but none of them seems to be the right candidate. And then there is the question, if a specialised canvas is a good idea at all.
This problem might be solved with the emergence of the aforementioned scene-graph library; instead of introducing a specialised library for custom paint operations, make that library the standard way.
GTK+ is not limited to X11 systems anymore. There are many GTK+ applications that have been ported to Windows and enjoy a surprising popularity there; Inkscape for example has a significant Windows user base. And OS X gets more important with every passing month. Some of these applications make extensive use of operating system features. Up to now, GTK+ featured only a limited set of functions to provide access to operating system functions, but the first solutions addressing this problem are starting to appear .
One of the GTK+ buzzwords of the last few month has been introspection. Introspection allows to, well, inspect an object, its methods, public members and its inheritance. This is not only very comfortable for debugging, it also allows for very easy bindings: automated bindings for your favourite programming language? Here it comes. It might still be a while until all parts are in place, but already the results are amazing .
It might still be a long time until GTK+ 3.0 gets released. And in any way; GTK+ 3.0 won’t be about adding new features. There are still some mistakes of the past lumbering in GTK+. Exposed private structues, public members that get manipulated directly: things like these have to be fixed before a GTK+ 3.2 can start adding features . But with some of the features, especially a scene-graph, window-independent widget placing and over-rideable paint methods for GTK+ widgets, GTK+ is starting to look very interesting again.
 Imendio’s GTK+ 3.0 vision
 Gtk+ Hackfest 2008: Day one and a half
 GUADEC 5 Notes
 New Theme API
 Canvas Overview
 libgtkhotkey 0.1, Portable Hotkey Integration
Future of GNOME language bindings
 GTK+ 3.0: Enabling incrementalism