Table of Contents
This chapter will try to provide a rapid orientation to tools and websites you should be familiar with, provide some pointers on pitfalls to avoid when starting to learn Gnome, and provide a simple project for the prospective Gnome developer to begin assisting the Gnome project and become part of the Gnome community.
In the past, Gnome documentation has had a bad habit of misleading new developers into a quagmire of irrelevant details. This has resulted in the frustration of many talented developers. This guide will try to point out a more appropriate set of steps in learning to develop with Gnome, but there are a few notable things to avoid that I will point out in this section.
First on the list is the auto tools (autoconf, automake, and libtool). These tools are designed to assist in handling the complexity inherent in porting your application to a wide variety of platforms. But learning how to make your application, which does not yet exist, portable to every bizarre platform ever created before learning how to write the actual application is more than a little backwards.
gettext, intltool, and popt are similar. gettext and intltool are designed to assist with internationalizing your application (i.e. making your application so that it can easily be translated into other languages), while popt is designed to parse arbitrarily complex command line options. Just as with autotools, learning how to make programs general before learning how to write an actual Gnome program is pretty backwards.
Next on the list is compiling Gnome from source code, specifically from CVS (the up-to-the minute bleeding edge version of Gnome). While providing bugfixes against the most recent development versions can be a good way for some people (with the right background and personalities) to start, it is not a task for everyone. Although compiling from CVS has a number of benefits, it can never be made an easy task for beginners because it is impossible to predict when and where problems will occur. This is because rapid changes to the source code could cause any of a number of things to fail and although such problems are fixed quickly, there are always new ones popping up. That is not to say that beginners cannot compile from CVS, it is just that doing so will take some patience...and requiring beginners to have patience in completing a task that is only peripherally related to what they need to learn is asking for problems.
There is another reason that compiling from source can be a bad direction to point beginners. Many people (or perhaps even most people) want to learn how to write their own applications using the Gnome libraries but do not want to work on programs and libraries that are part of the official Gnome Desktop and Developer Platform. For these people, there is virtually no use at all in compiling Gnome from source code.
Another obstacle often given to beginners is to start at too low of a level in the libraries. While GTK+ seems like an obvious starting point for beginners who want to learn to work with Gnome, a lot of it is fairly low level. For example, beginners are not going to need to know how GObject is an object oriented API for C or how it provides an object oriented framework that is easy to map into other languages. The only thing I can think of in GObject that is useful to a beginner is the signal connection functions. Another example of GTK+ being too low level is widget packing. This is a very tedious and boring process for any but the simplest of interfaces, and Glade and Libglade provide such a beautiful and simple alternative. One can similarly point out that many other parts of GTK+ are at too low a level. In fact, I believe that most users can and should start with Glade and Libglade. I believe that as they do so, they can "get the hang" of enough of GTK+ to write useful basic applications. They can then refer to the GTK+ tutorials and API documentation as needed.
Finally, a discussion of what are low level details would not be complete without discussing the language itself. While the core of Gnome is implemented in C, it was designed with other programming languages in mind and therefore has perhaps one of the cleanest and most comprehensive set of language bindings of any toolkit (see http://www.gtk.org/bindings.html). To quote Owen Taylor, "Don't use C; In my opinion, C is a library programming language not an app programming language." Now, of course, if you want to work on existing Gnome applications, you should use whatever language that application is written in, and that will usually mean C. But for those starting their own projects, they will probably want to pick a different language. This guide provides all example programs in C and C++ and Perl and Python to assist you in doing so. However, this guide is biased toward the C bindings as one of my original goals in writing it was to encourage more people to work on existing Gnome applications and libraries, most of which are currently in C.