ACPI has always been a problem for the Linux kernel. Be it suspend and resume, power management, screen brightness or any other function provided by ACPI; it never really worked for and with Linux. The reason for that is the immense size of the ACPI specification. And the fact that almost ever manufacturer has a private interpretation of said standard.

The solution for Linux, up to now, was to stop being Linux and pretend to be Windows, e.g., emulate all the bugs and implementation details of Windows’ APCI implementation and hope that it somehow works. Most of the time it did. Sometimes it didn’t. And instead of blaming the manufacturers and Microsoft for not adhering to the standards, Linux was blamed for trying to implement the ACPI standard to the letter.

However; this is – hopefully – going to change. For Intel released a new firmware interface (providing all the functionality of ACPI), with a reference implementation for – you guessed it – the Linux kernel. And whereas the APCI standard (version 4.0 was released only recently) spans over 727 pages (http://www.acpi.info/spec.htm), the new firmware interface (http://simplefirmware.org/) needs only 9 pages in its current incarnation (draft 0.6).

Now SFI is not going to change the world overnight. But I hope to see SFI gaining traction within the next three to five years. I’m crossing my fingers.

Now it’s official; for the first time ever Microsoft sued another company over patent issues related to the use of Linux. Now we’re really in the ‘Fight’ stage of Ghandi’s old saying: “First they ignore you, then they laugh at you, then they fight you, then you win.” Tomtom was sued for the use of the FAT file system in some of its devices. Apparently there are some patents related to the inherent filesystem-management of Linux. I’m curious how these hold up in court.

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.

Don’t take this article too serious. I had a lot of fun writing it. I do believe that GNU/Linux is coming to the desktop in 2008, however.

When I first started to work with GNU/Linux, now almost eleven years ago, I’d never would have guessed that it would become such a large part of my life one day. I liked the idea; communal developed software. Collaboration on a whole new level. Software not developed by a company, but by enthusiasts. It had something rebellious and subversive. I just fell in love with it.

Back than, GNU/Linux (and the BSDs also) was merely a toy for me. Something fresh, something new. Something completely different. But after I had set up my first servers, had started using October Gnome as my desktop environment, I started digging deeper. Into the internals of the system. Into the Source.

I always considered myself to be a fairly good coder. Not excelling, but competent. And because of that I recognised the quality of that code. I realized that that those little pieces of code were the works of mad genious artists. Pure, elegant C, honed to perfection.

I was convinced that it would – one time – rule the world.

Yet I always fooled myself about GNU/Linux’ problems. Back then, getting X to run was a task of days, at least on the hardware at my disposal. The desktop environments were clumsy and counter-intuitive, the applications limited and ugly, for they were written with either CDE or Tcl/Tk. Most didn’t even have a graphical user interface and were limited to the console. XMMS was okay for playing MP3 files, but even watching a move was a daunting task. Those were the dark ages, when the Knights of the Light only had started their quest for freedom and equality.

Even back then there have always been Prophets of The Dawn. Reiterating the old prophecy that this, yes, this very year would come to be known as the Year Of The Linux Desktop. I always used to simile at them and give ’em cookies. They were cute, somehow. Breaking the Mighty Power of the Forces Of Evil would be the task of a generations. The desktop market was fixed in the hands of Microsoft, a convicted monopolist. An unpleasant necessity. Breaking that power would be a task for giants.

While I was promoting GNU/Linux in my surroundings, providing installation setup, first private, than commercial, the Amazing Power Coders were out there. Doing good wherever they could. And one by one, Linux’ weaknesses were being addressed, scrutinized, judged and attacked with the fury befitting a wildcat.

Things have changed. GNU/Linux has changed. X.org, KDE, GNOME, Linux and all the other pieces of software composing the free software desktop have ripen well. It’s functional software, mostly slim and elegant, sometimes even beautiful.

Today I saw an advertisement for the Asus EEE PC, printed by a large consumer electronic store (Mediamarkt). This is the first time, that a GNU/Linux product has been advertised by that company. A company that has no ideology whatsoever. Besides making money. In the last few month no week passed by without the announcement of yet another GNU/Linux desktop/consumer product. Mostly ultra-lowcost ultraportable. Because these are the areas where GNU/Linux shines like a twinkling star.

And there is more. In two weeks there will be an anniversary. The anniversary of “GNU/Linux preinstalled on the desktop machines of a major hardware vendor”. It’s almost been a year since Dell announced to ship desktop and consumer products with Ubuntu pre-installed. HP followed shortly thereafter. And although neither Dell nor HP are making huge profits by selling GNU/Linux machines, both still provide the option. Even after a year.

With the rise of those consumer machines GNU/Linux got a lot of advertisement. And suddenly people I never talked to before about GNU/Linux start asking questions. They ask for support, for guidance and help. Some even offer to pay. Finally.

And the disbeliever, the skeptic inside, is falling silent.

So, now hear my prophecy, as I am joining the ranks of the Enlightened; The GNU/Linux desktop is coming. 2007 saw the end of the beginning. 2008 will feel the torrent.

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 [1] 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 [2] 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:
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 [3]. 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.

Animations:
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 [4].

Canvas:
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 [5] 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.

OS integration:
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 [6].

Introspection:
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 [7].

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 [8]. 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.

Yesterday I updated my work laptop to Ubuntu 8.04. Of course it’s silly to abuse a productive machine as a testing ground for a unstable release, but I did it, nonetheless.

My impression so far is very good! Even “Hibernate” and “Suspend” seem to work now, very nice. The only problem I had was with VMware Server, the only piece of proprietary software I use on my machine. For business reasons. However; the problems I had were fast to fix.

Patch the VMware modules.
VMware does not yet support Linux 2.6.24, so the modules have to be patched. The VMware community forums helps with that: http://communities.vmware.com/thread/121847?tstart=-1
Don’t forget to edit …/source/vmmon-only/include/vcpuset.h, you need to change line 74 from “asm/bitops.h” to “linux/bitops.h”. (Thanks to luyseyal for that.)

Re-compile the modules.

Just use sudo vmware-configure.pl to recompile the modules.

Copy the libraries
The VMWare Server Console was compiled with an older version of the GCC than Hardy is compiled. If you get the following error, you need to copy some libraries:

/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)