Nerd Food: Gnome: A User Perspective

As it is known to all, KDE made a very pragmatic decision when things were starting off and chose Qt as their toolkit. It was a decision based purely on technical merit, and on these grounds Qt had no real competitors. Unfortunately, Qt was not under a free license then (free as in speech), so this provoked a reaction from the GNU-er side of the community. Led by Miguel, developers got together and formed the Gnome project, with the goal of developing a totally free desktop environment. With time, Qt was re-licenced under the GPL, but by then it was too late — too much effort had already been done.

Now, apart from all the nasty things that have been said by both sides and worldwide trolls, this event marked the future progression of these two projects. You see, KDE started off with a mature toolkit that offered many things programmers expect: a) a good, well documented API b) a lot of abstraction from GCC's problems with C++ c) a lot of man hours spent in making sure everything was in working order d) a lot of scope, being more of a framework for application development than a toolkit.

With regards to d), I'm certainly not the right person to talk about Qt's merits as I have never done any development with it; but a quick glance at KDevelop shows me that it includes support for containers, XML, DOM, a socket abstraction, FTP, and a lot more.

Also, one should not treat a) lightly. From my knowledge of wxWindows, Qt appears to be very well designed and quality of its design surely teaches new developers to try to follow the same practice, especially with an OO language. And while we're talking about new users, I think we all agree when I say that documentation by itself is almost decisive when learning something new (hence why I'm such a big fan of wxWindows). No one likes to be struggling with the language while at the same time trying to make sense of third-party libraries.

On the other hand, things are quite different in our side of the fence. Whatever the circumstances were when decisions were made, we have to coldly deal with the present. Gnome folks are more like an architect who must worry about designing the building while simultaneously dealing with the production of almost all the materials he's going to use.

As things stand (1.4), we lack maturity in GTK, in some important Gnome libraries, in most of our applications and in our documentation. All of this with varying degrees, of course. At this point I can hear you say "Isn't that like, in everything?"

Well, you must bear in mind that there are only so many programmers we can throw at a problem, especially at the boring ones. Worst, we cant just stop everything and focus our attention in making the building blocks because we are not a company. This makes our users and new developers very confused: why do I need so many libraries to get ZXY going? Why can't I have the latest X package and the latest Z package simultaneously? Where's the documentation for XYZ? Why is your file manager slow? And the answer is normally "we're working on it!".

What we must not allow people to believe is that this is the Gnome way of doing things, that things are like they are on purpose. When they say "we're working on it!" they're actually working on it, and there's much to work on at the moment.

Gnome people are not bad developers, lazy gits who don't care about documentation, or schizophrenic people who hate integration and love having different address books for each of its many mail applications. Its just that they're juggling with many balls at the same time and its hard to compete with people that juggle with less balls. Sometimes you are developing an application and have to stop and create or improve an entire library before you can go back to what you were doing. Obviously some of those libraries end up not having widespread use while some others are seen as The Right Thing (TM). Its all part of the learning process.

And there's no point in saying "if you had started with a more mature toolkit, you'd be much better off", because when those decisions where taken the world was a very different place, regardless of which side you were on at the time, and now nothing can be done about it.

But for those that think this is a bleak view of Gnome, it isn't. There is an extraordinary amount of work being done in a very short space of time, most of it in things that are not visible to end users, and the mere fact that people still put Gnome in line with KDE demonstrates the quality of the work.

In fact, Gnome 2.0 will probably be a turning point in terms of professional-ness, because as time goes by the core gets stable and the side effect is we have more time on our hands so other things will get more CPU time and therefore improve; you cant worry about nifty documentation when the API itself is changing!

Alas, when maturity is reached, we can count on our friends at SUN or IBM to start a professional documentation of all of the API, together with some nifty examples that will make any newbie a Gnome developer in no time. They'll be very interested in doing so by then, believe me. By then we'll also have a couple of nice IDE's to chose from so things will be much better for people starting.

I have to say I am a big C++ fan; its my main language and I appreciate its elegance. But honestly do not believe the language is playing too important a role here. Lets think: in a UNIX environment, how many hackers are experts in C? How many have done it for years, and are experienced in developing large, complex applications?

In fact, if we look at the work of a famous writer in OO theory, Bertrand Meyer, we can see that many of the things he considers to be determinant factors in a program are present in many C programs: robustness, correctness, extensibility, re-usability, compatibility, efficiency, portability. All of these apply to our beloved kernel — excelling in some — and its done in C¹. Influenced by Meyer's thinking, I too believe OO is more of a way of thinking than it is a language, although languages can embody a bit of that way of thinking — and some do it more than others. While being designed strictly for OOP is an important advantage, it cannot be denied that years of experience produce results that are quite close to it.

C++ is a language that requires a lot of experience in OO, a lot of theory to get the design right and that's why most large free software projects tend to be rather bad when done in C++ — being Abiword, Mozilla, KDE and its applications some notable exceptions. I believe there is a very good explanation for these exceptions. All of the projects share one fact in common, and that is there were some very experienced C++ hackers that laid out the foundations, making tough structural decisions at an early stage. For instance, look at Abiword's source one of these days and you'll see things along the lines of Design Patterns; the code is absolutely marvellous. That's not work of a kid in college that is learning as he goes along.

More: to get a lot of people to that sort of level you need solid and proven standards, a good compiler that respects those standards, lots of time and lots of sample code to learn from. C++ just hasn't been out in the free software community long enough for us to have many expert hackers as we have in C. The standards are new (1998, I believe), the compiler is just out, the sample code is quite daunting and complex. The successful projects solve some of these problems by re-inventing a lot of the core functionality of C++ (for example, the STL is not very popular).

Please note that I'm not saying KDE is where it is solely because its based on Qt; KDE developers have a lot of merit for things like their own object model, Konqueror, KDevelop, and many, many other applications that are astonishing accomplishments which cannot be argued with. But an important part of its structure is inherited from Qt and that gave them the solid foundations on which to build.

My point being, it has little to do with the language and a lot more to do with maturity. Soon, when GTK reaches a level of maturity comparable to Qt, we'll see a lot less people saying that C is dead. There's just far too many good C hackers for that to be the truth.

The second issue I think is interesting is the role of Ximian in the Gnome community. Their merit, knowledge and spirit cannot be argued with. But unfortunately, having a center of gravity as large as Ximian is generating some friction. Lets go through some problems we have at the moment.

It is most annoying when you get a Red Hat machine and it starts with a Red Hat Gnome, and I'm sure most people feel the same way. Red Hat is sometimes conservative on their tastes — so we don't get the most up to date stuff like we're used to with Ximian (or were used to…); and for those unfortunate enough to live where Dial Up is king, upgrading is an issue.

Besides, even if you do have the latest Gnome packaged by Red Hat, you may want to install something distributed by Ximian or vice-versa and although things may work well together, the idea of installing a package from different distros is daunting. Its almost like installing a Mandrake RPM in a Red Hat box: its probably scarier if it installs without any error messages.

My view here is that we do not need this duplication of efforts, and I think it is doing a lot of damage in terms of public image. Just try to explain this to a newbie: not only there are multiple distros for the operative system, there are also multiple distros for the desktop environments!

There's also the issue of package selection, or in other words, what gets included and what doesn't. A KDE standard install includes a lot more applications than a Ximian Gnome one, and that's not because of the lack of GTK/Gnome apps. Part of it is possibly to do with commercial reasons: Ximian wants a stable product, not a mix between solid and bleeding edge. Or it may be that they don't want to have to package too many things, instead they prefer to do less and do it well.

Either way this is where things get tricky: if they're the main packager we're stuck and we represents mainly the Dial Up crowd that can't spend hours hoping from site to site to get all the libraries and then get the new apps.

So what do we need? I can see some solutions:

• We need to stop this packaging nonsense of my Gnome and your Gnome. We need to have a standard packaging the Gnome core, with all the libraries needed. That someone should be the distro. So Red Hat would make RPM's for all the platforms it runs on. This core is distributed as one package, that you can install or un-install easily.
• This same core offers a set of tools that allow customisation without rebuilding: change the initial splash screen, change the menu's, etc. so that a distro can configure it without having to rebuild it. And that should be the same for all platforms, different binaries but same contents.

Just my two cents.

Back to essay index

Back to home page