GNOME Programming in Linux using GTK+

The code samples provided along with the text have been checked on a computer system with the following configurations: Compaq Presario 4010 Series computer system, 15.5 GB Hard Disk Space, 96 MB RAM, 400 MHz Intel Celeron Processor, Red Hat Linux 7.1 Distribution Release underlying Kernel: 2.4.2-2

This article has been divided into the following sections for easy understanding of the subject matter:

1. What is GNOME all about? An Introduction.
2. The GNOME Architecture.
3. GTK+ - An Introduction
4. A basic program.
5. Signals & Callbacks
6. Containers
7. Buttons
8. Entry Widgets
9. List boxes & Combo boxes
10. Menus & Toolbars
11. Dialog boxes
12. Conclusion & Links for Further study

What is GNOME all about? An Introduction.

Before entering into the exciting world of Gnome programming in Linux, let's try to understand what Gnome actually refers to. GNOME is the acronym for "GNU's Not Unix Network Object Model Environment". Though it sounds a bit complicated, Gnome is a software project with a simple aim: To provide all Linux users with an extremely user-friendly yet powerful and complete programming Desktop environment. GNOME is currently the default Desktop system installed with the latest releases of Red Hat and Debian Distribution releases of Linux.

For more specific info on GNOME and its various wonderful features, make sure you check out the GNOME Project home page at www.gnome.org which provides readers with a wealth of information on GNOME, including online documentation, news; and one can also download the binaries and source code of GNOME compatible with most Linux systems.

Now let's try to look at GNOME from both a "Linux programmer's" as well as a "Linux System Administrator's" point of view. The basic question that comes to mind is: Do they think and feel the same when they talk about GNOME? The answer to this question is not straightforward. Most Linux system administrators currently are, or have been, Linux programmers in the past and that makes this quite a difficult question to answer. For an average Linux system administrator the GNOME environment provides a wealth of tools that makes his or her administrative job so simple, while it is the duty and responsibility of the GNOME programmer to continue providing these facilities by designing even better programs. So, they are in perfect harmony with each other as far as their respective works are concerned.

Now let's take a bit closer look at Gnome's functionality. GNOME is actually a programming layer placed in between the X Window System (or X) and the Window Manager software. Thus, as mentioned earlier, it provides Linux GUI programmers with an enormous functionality they can harness to design Linux based programs. But most significant of all, the reason why GNOME is nearly indispensable for all Linux/Unix developers is because GNOME provides these developers/programmers with an Integrated Framework that was specifically designed for building open-source applications with a consistent graphical user interface.

The GNOME Project started in August, 1997; some of the initial founders included, amongst others, Peter Mattis, Spencer Kimball, Richard Stallman, and Erik Troan and Mark Ewing of Red Hat, Inc.

Let's now take a look into the GNOME Architecture.

The GNOME Architecture

Now we come to a very significant portion, the GNOME Architecture. It is this extremely powerful, yet flexible architecture that provides GNOME its terrific functionality. The base toolkit in GNOME is named GTK+ (the GIMP toolkit). It was originally written for using in the GIMP (GNU Image Manipulation Program). The proper understanding of GTK+ is extremely necessary for the understanding of GNOME Programming. GTK+ is an object-oriented, cross-platform language-neutral toolkit that is primarily used for creating applications independently of GNOME. Then the question that comes up is: Then why was GTK+ chosen as the toolkit for GNOME? The answer is simple: It was for its support for many programming languages including C, C++, PERL, Python, ADA etc. But it is helpful to keep in mind always that both GNOME as well as GTK+ are written using C; so we will be dealing here with C only.

Another question that may come up in the reader's mind is: Hey, what do these things called "Toolkits" contain? Toolkits like GTK+, Qt (the KDE Environment is based on Qt) are collections of widgets. Which begs the question: What are "Widgets"?

Widgets are GUI objects like buttons, menus, dialog boxes and other such objects or object-related general functions. This can be compared with Active Template Library (ATL 3.0) on the Microsoft Platform, which provides Component Object Model (COM) developers with a ready-made framework for creating COM Objects and Components (ActiveX EXEs & ActiveX DLLs).

GTK+ - An Introduction

Now let's take a closer look into some of the features of GTK+. They have been provided below in a tabular format:

1. The set of libraries used by GTK+: GLIB(GIMP Library) and GDK(GIMP Drawing Toolkit).
2. GLIB defines data-types and provides functions that deal with error handling and memory routines.
3. GDK is the platform dependent layer that is present in between the native graphics API and GTK+.
4. That's not all. GNOME adds further functionality to GTK+ by adding a separate layer of GNOME specific widgets and libraries.
5. Thus, GNOME comes with a full-featured, object-oriented extensive widget set enabled architecture.
6. Other than functionality of GTK+, we also have the added benefit of a Custom implementation of the CORBA system called ORBit in GNOME architecture, allowing software objects to communicate easily and effectively.
7. GLIB defines its own set of basic data types. Most of these are equivalent to the standard C data types.

GLIB data type C type gchar Char gshort Short glong Long gint Int gboolean Boolean gpointer void*

A vital requirement for proper understanding of GTK+ is the concept of "Widget Hierarchy". Widgets in GTK+ belong to a hierarchy so that functions that are common to a set of widgets need only be implemented once. For example, the function gtk_widget_show: This leads to the removal of duplicate codes. Thus leading to better and faster program development. The point to be kept in mind is always: new widgets are derived from existing higher-level widgets so that only the new features of the widget need to be written by the programmer. For example, let's look closely to this particular widget hierarchy:

GtkObject
    --> GtkWidget
        --> GtkContainer
            --> GtkBin
                --> GtkWindow
                    --> GnomeApp

Thus, if you look carefully, you can see that GnomeApp widget is derived from the higher-level GtkWindow, which itself has been derived from the higher-level GtkBin and so on. If we take into the consideration the essential features of the C++ programming language, well, this reminds us of the concept of "Inheritance". Doesn't it? Well, surely it does. And it is this feature of the "Widget Hierarchy" that incorporates the derived functionality in GTK+.

Let's now take a brief look at the widget creation functions. For these functions to operate correctly one must make sure that all the GNOME and GTK+ libraries are correctly installed. Another important thing to be kept in mind is that the library's path must be correctly set before trying to compile any code.

Let's first consider the widget creation function, gnome_app_new( ). This function as shown returns a GtkWidget pointer, which is the generic widget. This maybe shown as:

        GtkWidget *ghosh;
    ghosh = gnome_app_new(.........);

Please note that this also means that if we want to call a GnomeApp specific function such as gnome_app_set_menus( ), then we have to use a macro to perform the cast from a GtkWidget type to a GnomeApp type; which is only possible because GnomeApp is derived from GtkWidget (consult figure above).

A Basic Program

The best way to learn Linux programming is to understand the internal workings of the Kernel and by doing programming yourself. So, let's now look at a small program to understand the subject matter better.

Boot your system in Linux, and if you are in the CLI (command line interface) mode, switch over to gnome, using the command "switchdesk gnome", and then issue a "startx" command to boot into the X Window System GUI mode. Once into the GNOME environment, open the GNOME Terminal, create a file named myapp.c using vi, and type in the following:

/* A sample GNOME program 
   Created By: Subhasish Ghosh
   Date: 4th July, 2001
*/

#include <gnome.h>

int main(int argc, char *argv[ ])
{
    GtkWidget *ghosh;
    gnome_init("sample", "0.1", argc, argv);
    ghosh = gnome_app_new("sample", "My Window");
    gtk_widget_show(ghosh);
    gtk_main( );
    return 0;
}

Now, to compile the program myapp.c, make sure you type in: (note the back-ticks carefully)

# gcc myapp.c -o myapp `gnome-config --cflags --libs gnomeui`

Note, GNOME comes with a shell script named gnome-config that supplies the compiler with the correct flags required for compilation. Once compiled, run the program using the command:

# ./myapp &

and press enter.

An empty window will appear on the screen, which you can move, resize, as well close. Now, let's take a closer look at the code. At the top we included a few commented lines describing the program, it's creator and date of creation. Though not necessary it's a good programming practice to include these in each and every program. Then, we included the header file, gnome.h that takes care of all necessary GNOME and GTK+ library functions and definitions. Then comes "ghosh", which is a GtkWidget pointer. This would point to our new Window object. The function gnome_init is then called. It initializes libraries, and is used for correct session management. The ID passed to this gnome_init function is "sample", the version number being "0.1", and then the usual command line arguments of main. These are necessary for the internal workings of GNOME. Then comes the function gnome_app_new( ), which when executed, creates our window. This takes two arguments as shown in the sample code: "sample" and "My Window", where "sample" is the application name, and "My Window" being the window title. But please note: Though the name of this function is gnome_app_new( ), it does not create any sort of new application. It creates a top-level window. That's all. The next function being called is gtk_widget_show( ), which makes our window visible. Next comes gtk_main( ) which is a very important function, as it makes sure that GNOME functions like events, button presses and such, are executed, by handing on the functionality to GNOME.

So, that's the internal workings of our first GNOME program.

Signals & Callbacks

Now let's take a deeper look into the GNOME programming environment. Let's talk about "Signals" and "Callbacks" here. The first obvious question that comes to the reader's mind is: Hey, what are these and what are they used for? Do we really need them? Well, let's try to answer these questions by closely looking at them. Every single time the mouse moves, enters and leaves widgets, buttons are pressed, toggle buttons are toggled on or off, and such things are done, a signal is sent to the application. This signal can be passed to a callback function. Most of the time applications will need to connect to these events for taking certain actions. In GNOME/GTK+, we call a function called gtk_signal_connect to connect signals to handler functions.

The gtk_signal_connect function has the following four parameters:

1. GtkObject *object --> Which widget the callback is associated with.
2. const gchar *name --> The signal to be handled.
3. GtkSignalFunc func --> The function to be called when the signal is sent.
4. gpointer data --> Any arbitrary data to be given to the signal handling function.

It should be noted that various kinds of widgets emit different signals. The signals from buttons are as follows:

1. clicked --> Button clicked (pressed & released).
2. pressed --> Button pressed down by mouse.
3. released --> Button released.
4. enter --> Mouse moved over the Button area.
5. leave --> Mouse moved out of the Button area.

We will see how signals and callbacks play a vital role in the applications that we develop later.