The GNOME Project

What is GNOME and where is it heading? Miguel tells us all.
Other Donations

The GNOME project received a monetary donation from the GNU/Linux Debian team in the early stages of the project, as well as an Alpha board from Quant-X Service and Consulting GmbH. We are very grateful for their contributions.

Some Key GNOME Features

The GNOME libraries provide a framework to create consistent applications and to simplify the programmer's task. More features of the GNOME libraries will be described later. Some of the most important current developments in the GNOME libraries are discussed here.


One problem faced in a desktop environment is the fact that it is usually necessary to have a mechanism for storing information about a file's properties. For example, applications might want to bind an icon for a specific executable file, or bind a small thumbnail image for a graphic produced by a graphics program. These icons should be semantically attached to the main file.

The Macintosh OS, for example, provides a way to store this information in the file as its “resource fork”. This mechanism would be awkward at best to implement in a UNIX environment. The main problem is that a non-metadata-aware application can cause the metadata information to get out of sync.

The GNOME metadata was implemented by Tom Tromey at Cygnus, given a number of design constraints and tradeoffs (described in detail on their web site). The following is a list of the GNOME metadata features:

  1. Binding the information on a per-file basis in a per-user setting, and each user keeps track of his own bindings. System defaults apply on top of these.

  2. Binding information by file content is done according to the file type using file signatures, similar to the UNIX file command.

  3. Binding information by a regular expression: for example, a default icon for gif files would be provided by the regular expression .*\.gif$.

  4. The metadata system is optimized to provide a coherent GUI solution, rather than as a compromise or kludge to existing command-line tools.

  5. Most ordinary uses of files will continue to work without metadata, just as they do now.

A number of standard properties for file metadata are available in GNOME. For example, “View” stores the action for viewing the file contents; “Open” stores analogous action for editing; “Icon”, which contains the icon, is used for displaying the file on the desktop.

Metadata types are MIME types.


GNOME provides a Canvas widget, patterned after Tk's excellent canvas. This widget simplifies the programming of applications that need control over graphical components. The most noticeable feature of GNOME Canvas is that it provides a flicker-free drawing area where high-level objects can be inserted and manipulated. Basic zoom and scroll facilities are also a part of the canvas.

Figure 4

The high-level objects inserted into the canvas behave like regular widgets. They can receive X events, grab the focus and grab the mouse just like a regular widget. As with their Tk counterparts, GNOME Canvas items can have their properties changed at runtime with a Tk-like configuration mechanism.

The GNOME Canvas ships with a number of items derived from the GnomeCanvasItem object: lines, rectangles, ellipses, arrows, polylines and a generic widget container to embed GTK+ widgets within a canvas. The Canvas framework is designed to be very extensible. As proof of this extensibility, the GNOME spreadsheet is implemented on top of the base canvas engine, with additional functionality provided by spreadsheet-specific CanvasItems.

Note that the current Canvas uses Gdk primitives (a thin wrapper over Xlib primitives) to draw, so it is limited in the quality and range of special effects that can be provided with it, which bring us to the next step in Canvas technology.

Raph Levien is working on an advanced rendering engine for the Canvas. It was originally developed as a stand-alone widget within his Type1 outline font editor, gfonted. At the time of this writing, work on integrating the engine into the Canvas was getting underway.

Features of this engine include:

  • Anti-aliased rendering of all items

  • Alpha transparency

  • Items for vector and bezier paths

  • Items for RGB and RGB plus alpha images

  • Vector operations, including clip (intersect), union, difference and stroke layout

  • PostScript Type1 font loading and rendering

The engine's design goal is to support almost all of the PostScript imaging model with the addition of alpha transparency. As such, it is expected to be an excellent starting point for high-powered graphics applications.

In spite of the ambitious goal of keeping the display up to date with entirely anti-aliased and alpha-composited items, performance is surprisingly good—comparable, in fact, to the Xlib-primitive-based canvas engine.

His code is expected to be merged into the main Canvas sometime soon.

Window Manager Independence

GNOME does not depend on a special window manager—any existing window manager will do. GNOME specifies window manager hints that can be implemented by the window manager to give the user better desktop integration, but they are optional. The E window manager implements all of the GNOME window manager hints and can be used as a reference implementation for people wishing to extend their window managers to be GNOME-compliant. The ICEWM manager is tracking those developments and is also considered to be a GNOME-compliant window manager, although at this time, it is lagging a bit behind. A few people have shown interest in providing the WindowMaker and FVWM2 maintainers with patches to make those window managers GNOME-aware.

Component Programming

Historically, one of the attractions of UNIX has been the philosophy of small tools that each do one thing well and combining these tools, using pipes and simple shell scripts, to perform more complex tasks. This philosophy works very well when data objects are represented as plaintext and operations are effectively filters. However, this UNIX command-line philosophy does not scale well to today's world of multimedia objects.

Thus, it would be nice to have a framework in GNOME that would provide software reuse and component plugging and interaction, i.e., connecting small specialized tools to carry out complex tasks. With this infrastructure in place, GNOME applications can once again return to the UNIX roots of simple, well-specialized tools.

An RPC system was then required for providing this sort of functionality, so we decided to use CORBA (the Common Object Request Broker Architecture) from the Object Management Group (OMG). CORBA can be thought of as an object-oriented RPC system, which happens to have standardized bindings for different languages.

CORBA opened a range of applications for us. Component programming allowed us to package programs and shared libraries as program servers that each implement a specific interface.

For example, the GNOME mail program, Balsa, implements the GNOME::MailMessage interface that enables any CORBA-aware program to remotely compose and customize the contents of a mail message and send it. Thus, it is possible to replace the mail program with any program that implements the GNOME::MailMessage interface. As far as the GNOME desktop is concerned, the process just implements the GNOME::MailMessage interface. This means, for example, that I will be able to continue using GNUS to read my mail and have GNUS completely integrated with the rest of my desktop. This also applies to the other components in the GNOME system: the address book, file manager, terminal emulation program, help browser, office applications and more.

Beside providing the basic GNOME interfaces, applications can provide an interface to their implementation-specific features. This is done by using CORBA's interface inheritance. A specific interface would be derived from the more general interface. For example, GNUS would implement the GNOME::MailMessage interface and extend it with GNUS-specific features in the GNOME::GnusMailMessage interface. This interface would hypothetically allow the user to customize GNUS at the Lisp level, something other mailers may not do. Another example would be a GNOME::MozillaMailMessage interface that would let a user configure the HTML rendering engine in Mozilla mail.

Not only does CORBA address these issues, but it can also be used as a general interprocess communication engine. Instead of inventing a new ad-hoc interprocess communication system each time two programs need to communicate, a CORBA interface can be used.

Embedding documents into other documents has been popularized by Microsoft with their Object Linking and Embedding architecture. A document-embedding model similar in spirit is being designed for GNOME (the Baboon model), and all of the interprocess communication in this model is defined in terms of CORBA interfaces.

Initially, we were very excited by the possibilities CORBA presented us, but we soon realized that using CORBA in the GNOME desktop was going to be more difficult than we expected.

We tried using Xerox's ILU for our CORBA needs. The license at the time did not permit us to make modifications to the code and redistribute them, an important thing for the free software community, so we had to look for alternatives. Xerox has since changed the licensing policy.

After evaluating various free CORBA implementations, we settled on MICO, as it was the most feature-full free implementation. MICO was designed as a teaching tool for CORBA, with a primary focus on code clarity.

Unfortunately, we soon found that MICO was not a production-quality tool suitable for the needs of GNOME. For one, we found that the rather indiscriminate use of C++ templates (both in MICO and in MICO-generated stubs) proved to be a resource hog. Compiling bits of GNOME required as much as 48MB of RAM for even the simplest uses of CORBA, and this was slowing down our development. Another problem was that MICO supported only the C++ CORBA bindings. Even though an initial attempt had been made at providing C bindings, they were incomplete and not well-maintained.

To address these problems, Dick Porter at i2it and Elliot Lee at Red Hat Labs wrote a C-based, thin and fast CORBA 2.2 implementation called ORBit. As soon as ORBit became stable, the use of CORBA throughout GNOME began, after a delay of almost eight months.

With an efficient, production quality CORBA implementation under our control, we can ensure that CORBA-enabled interprocess communication is a valuable service for application programmers, rather than a source of overhead and bulk.