GNU’s Network Object Model Environment

GNOME is an acronym for GNU’s Network Object Model Environment. GNOME addresses a number of issues that have not previously been addressed in the UNIX world, such as:

GNOME’s main objective is to provide a user-friendly suite of applications and an easy-to-use desktop. As with most GNU programs, GNOME has been designed to run on almost all strains of UNIX-like operating systems.

The GNU GNOME project was initially announced in August 1997. After just one year of development, approximately two hundred programmers worldwide are now involved in the project.

The original announcement called for developers to shape the GNOME project in a number of forums: the GNU announce mailing lists; the Guile mailing list; and the GTK+ and GIMP mailing lists. The programmers and other people who influenced the project were mainly free software enthusiasts with diverse areas of expertise, including graphics programming and language design.

The GNOME team has been working steadily toward creating a foundation for future free software development. GNOME provides the toolkit and reusable component set to build the free software end users are eager for.

Our recent releases of the GNU Network Object Model Environment have been GNOME 0.20, the first version of GNOME that showed signs of integrations, released in May 1998; the Drooling Macaque 0.25 release, with more features; and finally, our latest public release, GNOME 0.30, codenamed Bouncing Bonobo.

The GNOME 0.20 release was the first release included in a CD-ROM distribution. Red Hat 5.1 shipped with a technology preview of the GNOME desktop environment and it was first demonstrated at the 1998 Linux Expo in North Carolina.

Before the Drooling Macaque release, GNOME software releases were coordinated by two or three people on the team. This became a significant burden, as precious time was being used coordinating each release. We have been trying to make the release process more modular and have assigned different modules to package maintainers. Each package maintainer is responsible for packing, testing and releasing their packages independently of the main distribution, which we consider to be the core libraries and the core desktop applications. So far we have had some success, but there is still room for improvement. We will continue to polish the release process to make it simpler.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1

 

 

 

 

 

 

 

 

 

 

 

 

Figure 2

The most recent GNOME release, Bouncing Bonobo, is the first to feature the GNOME spreadsheet Gnumeric.

In January 1998, Red Hat announced the creation of the Red Hat Advanced Development Laboratories (RHAD). The initial objective of Red Hat Labs was to help the GNOME effort by providing code and programmers and by helping us manage the project resources.

All code contributed to GNOME by Red Hat Advanced Laboratories has been provided under the terms of the GNU GPL and the GNU LGPL licenses. Several GTK+ and GNOME developers have been hired by Red Hat and they have rapidly provided the GNOME project with a number of important features.

For example, Rasterman has implemented themes for GTK+; the GTK+ themes allow a user to change the appearance of the widgets. This is done by abstracting the widget drawing routines from the toolkit and putting those drawing routines in modules that can be loaded at runtime. Thus, the user can change the appearance of applications without shutting them down or restarting the desktop.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 3

GTK+ themes are fully working. So far, a number of theme front-ends have been written. At the time of this writing, available themes include Motif, Windows95, Metal, native-GTK+ and a general purpose Bitmap-based engine (see Resources). The web site http://gtk.themes.org/ keeps an up-to-date list with many contributed themes from which to choose.

Various important changes to the GTK+ toolkit required for the GNOME project, such as the menu keyboard navigation code and the enhanced “Drag and Drop” protocols (XDND and Motif DND), were written by Owen Taylor, a famous GTK+ hacker now working for Red Hat Labs.

Assorted applications were created or are maintained nowadays by the GNOME team at RHAD as well: the Ghostscript front end (by Jonathan Blandford), the GNOME Help Browser and the GNOME RPM interface (Marc Ewing and Michael Fullbright), the GNOME Calendar and GNOME Canvas (Federico Mena) and the ORBit CORBA 2.2 implementation (Elliot Lee).

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.

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.

Metadata

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:

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.

Canvas

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:

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.

The toolkit

GNOME desktop applications have been built on top of the object-oriented GTK+ toolkit originally designed as a GUI toolkit for the GNU Image Manipulation Program (GIMP).

GTK+ has been implemented on top of a simple window and drawing API called Gdk (GTK Drawing Kit). The initial version of Gdk was a fairly thin wrapper around the Xlib libraries, but a port to Win32 and a port to the Y windowing system are presently in alpha stages.

GTK+ implements an object system entirely in C. This object system is quite rich in functionality, including classical single inheritance, dynamic creation of new methods and classes, and a “signal” mechanism for dynamically attaching handlers to the various events that occur in the user interface. One of GTK’s great strengths is the availability of a wide range of language bindings, including C++, Objective-C, Perl, Python, Scheme and Tom. These language bindings provide access both to GTK+ objects and to new objects programmed in the language of choice.

An additional feature of GNOME is Rasterman’s Imlib library. This library is implemented alongside Gdk and provides a fast yet flexible interface for loading and saving images and rendering them on the screen. Applications using Imlib have quick and direct access to PNG, GIF, TIFF, JPEG and XPM files as well as other formats available through external conversion filters.

The Support Libraries

C-based GNOME applications use the GLIB utility library. glib provides the C programmer with a set of useful data structures: linked lists, doubly linked lists, hash tables (one-to-one maps), trees, string manipulation, memory-chunk reuse, debugging macros, assertion and logging facilities. glib also includes a portable interface for a dynamic module facility.

The GNOME libraries

The GNOME libraries add the missing pieces to the toolkit to create full applications, dictate some policy, and help in the process of providing consistent user interfaces as well as localizing the GNOME applications so they can be used in various countries.

The current GNOME libraries are GTK+-Xmhtml, gnome-print, libgnome, libgnomeui, libgnorba, libgtop, gnome-dom and gnome-xml. Other libraries are used for specific applications: libPropList (soon to be replaced by a new configuration engine) and audiofile.

The main non-graphical library is called libgnome. This provides functions to keep track of recently used documents, configuration information, metadata handling (see below), game score functions and command-line argument handling. This library does not depend on the use of a windowing system.

As we use CORBA to achieve parts of our desktop integration, we have a special library called the libgnorba library to deal with various CORBA issues. It provides GUI/CORBA integration (to let our GUI applications act as servers), authentication within the GNOME framework and service activation.

The gnomeui library, on the other hand, has the code that requires a window system to run. It contains the following components:

GTK+-XmHTML is a port of the Koen D’Hondt’s XmHTML widget for Motif and is used for our HTML display needs. Our changes are being folded back into the main distribution.

The lib gtop library allows system applications to be easily ported to various operating systems; it provides system, process and file system information.

gnome-xml provides XML file loading, parsing and saving for GNOME applications and is being used in the GNOME spreadsheet (Gnumeric) and in the GNOME word processor program. gnome-dom provides an implementation of the World Wide Web Consortium’s Document Object Model for GNOME applications. By the time you read this article, gnome-dom will have been deployed widely in the GNOME office applications. Both gnome-xml and gnome-dom were developed by Daniel Veillard from the World Wide Web Consortium.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 5

gnome-print implements GNOME’s printing architecture. It consists of a pluggable rendering engine as well as a set of widgets and standard dialog boxes for selecting and configuring printers. In addition, gnome-print is responsible for managing outline fonts and contains scripts that automatically find fonts already installed on the system.

The GNOME print imaging model is modeled after PostScript. Basic operations include vector and bezier path construction, stroking, filling, clipping, text (using Type1 fonts, with TrueType to follow shortly) and images.

Currently, gnome-print generates only PostScript output. However, the design of the imaging model is closely synchronized with the anti-aliased rendering engine for the Canvas and it is expected that these two modules will be interoperating soon. In particular, it will be possible to “print” into a canvas (useful for providing a high-quality screen preview) and to print the contents of a canvas. This feature should simplify the design of applications which use the Canvas, as very little extra code will be needed to support printing.

The same rendering engine will be used to render printed pages directly without going through a PostScript step. This path is especially exciting for providing high-quality, high-performance printing to color ink-jet printers, even of complex pages containing transparency, gradients and other elements considered “tricky” in the traditional PostScript imaging model.

Bindings

One explicit goal of GNOME was to support development in a wide range of languages, because no single language is ideal for every application. To this end, bindings for both GTK+ and the GNOME libraries exist for many popular programming languages, currently C, C++, Objective-C, Perl, Python, Scheme and Tom.

The early involvement of Scheme, Tom and Perl hackers in both the GTK+ and GNOME projects has helped in making the GTK+ and GNOME APIs easy to wrap up for various languages. Multi-language support is “baked in” to the design of GTK+ and GNOME, rather than being added on as an afterthought.

GNOME is developed by a loosely coupled team of programmers around the world. Project coordination is done on the various GNOME mailing lists.

The GNOME source code is kept on the GNOME CVS server (cvs:cvs.gnome.org:/cvs/gnome/). Access to the source code through Netscape’s Bonsai and LXR tools is provided at http://cvs.gnome.org/, to help programmers get acquainted with the GNOME source code base.

Most developers who have contributed code, major bug fixes and documentation to GNOME have CVS write access, fostering a very open atmosphere. GNOME developers come from a wide range of backgrounds and have diverse levels of skill and experience. Contributions from less experienced people have been surprisingly helpful, while the older, wiser coders have been happy to mentor younger contributors on the team. The GNOME developer community values clean, maintainable code. Even programmers with many years of coding experience have noted how involvement with the GNOME project has helped them write better code.

As the GNOME foundation libraries become more stable, the development of larger programming projects has become possible and has allowed small teams of developers to put together the applications which will make up the GNOME office suite.

As with other GNOME components, the GNOME office suite is currently catching up with commercial offerings. By providing an office suite which is solid, fast and component-based, the code written for the GNOME project might become the foundation for a new era of free software program development.

The office suite leverages a lot of knowledge many of us have acquired during the past year while developing various GNOME components. Our coding standards are higher, the quality is better and the code is more clean and more robust.

The availability of these applications has provided us with the test bed we required to complete our document embedding interfaces (the Baboon model).

Two word processing projects are going on for GNOME: one of them is GWP by Seth Alves at the Hungry Programmers and the other one is Go from Chris Lahey. GWP is currently more advanced and has printing working with the GNOME printing architecture.

Gnumeric, the GNOME spreadsheet project, is aimed at providing a commercial-quality spreadsheet with advanced features. It provides a comfortable and powerful user interface. As with other components in GNOME, we have worked toward providing a solid and extensible framework for future development.

Recently, work has begun on Achtung, the GNOME presentations program. It is still in the early stages of development.

Tested source code releases of GNOME are available from GNOME’s ftp site: ftp://ftp.gnome.org/.

It is also possible to get the very latest GNOME developments from the anonymous CVS servers. Check the GNOME web page for details on how to pull the latest version straight from the CVS servers.

Breaking news about GNOME is posted to the GNOME web site in http://www.gnome.org/, along with documents to get you started on GNOME and developing GNOME applications.