 |  |
While GNOME can certainly make Unix-based operating systems more palatable to ordinary users, the GNOME team devotes a lot of energy to making GNOME fun to hack on, too.
From the developer's perspective, GNOME is made up of a set of core libraries, an infrastructure for component programming, and a set of reusable language-neutral components.
Many powerful features work across all GNOME applications in a standardized way, thanks to these libraries.
GTK+ is GNOME's object oriented graphics toolkit. It was originally designed by the GIMP programmers to simplify their work in building the GIMP. GTK+ was chosen for GNOME primarily because it implemented an object system rich in functionality and it already had interface bindings for a wide range of programming languages. This meant that GTK+ already went a long way towards achieving GNOME's goal of programming language neutrality. For more information, see http://www.gtk.org.
Guidelines have been developed that specify the method for adding new language bindings (wrappers) for the GTK+/GNOME libraries. Developers following these guidelines have contributed support for a number of languages, including C++, Objective-C, TOM, PERL, Python, GUILE, ADA, and others. Other bindings are in various stages of development, which is understandable, considering the large number of libraries that make up GNOME.
GTK+'s object system is very elegant in its design and allows for classical single-inheritance, dynamic creation of new methods and classes, and a signal mechanism that dynamically attaches signal handlers to events that occur in the user interface (e.g., a mouse click).
Another reason for choosing GTK+ is that it advances the second goal of the project--to create an intuitive desktop metaphor. It does this by providing support for two drag-and-drop protocols--Xdnd (X Drag and Drop) and Motif DnD. This makes it possible to drag and drop objects between programs written in GNOME (like the desktop), and programs that were written using other tools (like Netscape). Because all this is handled by GTK+, application writers get this functionality for free.
This is an imaging library and engine that provides for fast loading, saving, and displaying of images. Imlib provides sophisticated image caching and color-management functions which operate efficiently even on low-end displays or 8-bit video cards. Due to limitations in X's color management scheme, developers writing directly to the X Window System libraries and artists creating icons or images for X need to be concerned about how many colors a given image might use. Imlib frees them from these worries by providing automatic color reduction and dithering facilities.
The WWW Consortium (the organization that ratifies standards for the World Wide Web) recently introduced two new standards: XML and DOM. XML is the eXtensible Mark-up Language, which can be used to describe and create other mark-up languages such as HTML. With a well-written XML library in-place, GNOME developers can very easily add support to their applications for portably loading and saving structured data. DOM (Document Object Model) is a model that describes how applications can modify chunks of data in an XML document. Implementing these standards as a GNOME library makes it easier for programmers to write XML/DOM aware applications.
The Canvas is an engine for creating structured graphics that allows programmers to easily create interactive graphics displays. Its features include unlimited scrolling and completely flicker-free operation. The programmer simply creates a canvas item (stock items include text, images, polygons, and Gtk widgets) and specifies its location. The Canvas handles the rest.
The Canvas is designed to be an extensible, but generic, display engine. The Gnumeric spreadsheet application, for example, uses the Canvas to display the spreadsheet but provides its own custom extensions. Applications like the GNOME calendar and the Midnight Commander file manager use the basic functionality of the canvas in their displays.
Libart is a vector manipulation and rendering engine that uses anti-aliasing and alpha-compositing. The canvas is built upon Libart, which it uses to render its objects into an RGB buffer. Libart makes it easy for the canvas to create anti-aliased, alpha-composited output. Libart provides a superset of the PostScript imaging model for extremely high-quality output.
Bonobo is the name of the GNOME project to create a component model and a standard for the interactions between the components of a compound document.
It's a framework similar in concept to Microsoft's Object Linking and Embedding (OLE). Bonobo allows programmers to create reusable software component objects (similar to Active X Controls). It is also a document model that defines a system where these objects can seamlessly interact within shared container documents (Similar to Linking and Embedding).
To use an example that many people are familiar with, in Microsoft Office, an Excel document can be embedded within a Word document. The Word document in this case is a container document. It contains both the Word data and the Excel data. However, clicking on the Excel data allows you to work on it as though you were working in Excel, even though it is embedded in the Word document. The Excel application functions as a piece of component software, creating the illusion that the user is only interacting with one application.
Bonobo is a set of CORBA interfaces that are necessary for component design and interaction. The Bonobo interfaces are both language- and toolkit-independent, and Bonobo components can be both written and used in any language. The reference implementation of Bonobo is based on the Gtk object system and maps CORBA interfaces to Gtk objects which can be easily manipulated by the application author.
Note that while many programmers associate OLE with great complexity, much of that is due to the way Microsoft was forced to design OLE so that it would work well with Windows. While sharing much of the same functionality as OLE, Bonobo is inherently a much simpler system to understand and design software with.
Unix has long been praised for making it easy for users to take a bunch of small filter programs (like grep and sed ) and tie them together using pipes to compose a more complex, makeshift application. Sadly, pipes and filters do not scale to more complex applications (especially graphical applications). GNOME is an environment in which software objects can talk to each other (even over networks) in a standard fashion without knowing anything about each other. This is made possible by GNOME's CORBA foundation.
CORBA is a software system based on completely open standards, specifying methods for software objects to interact with each other. These objects speak to each other through an Object Request Broker (ORB), which directs traffic between all of the different pieces of software. The CORBA standard specifies the functionality that an ORB must provide to client programs that make requests of it. The objects don't need to know anything about each other; they can be programs that can be written in different languages and perform different functions, and they can even be located on different machines. As long as they communicate through the ORB, they can all speak to each other.
CORBA is woven throughout GNOME and provides application developers with a rich set of services. Among them are:
In the past, it was quite common in a Unix environment for programmers to invent a customized protocol in order for two applications to communicate. Needless to say, the situation did not do much to encourage software reuse or interoperability. Now, whenever GNOME applications need to communicate, they can just use CORBA.
Many applications in GNOME export their internal functionality to the outside world. This allows other programs--both GNOME and non-GNOME--to use the services exported by an application, making these applications especially accessible to scripting languages. In particular, exporting makes these applications accessible to scripting languages so that advanced users can write scripts that automate common tasks. In the not-too-distant future, the user will be able to write a Python script to manipulate a Gnumeric spreadsheet, perform customized spell checking, or automate repetitive presentation creation tasks. This is similar to the functionality that Microsoft's Visual Basic provides Microsoft Office under Windows. The Guppi graphics application, the file manager, and the Gnumeric spreadsheet are currently scriptable in this fashion.
As previously mentioned, the Bonobo component and document model expands upon the services CORBA offers, creating a framework that offers both programmers and users a very high level of flexibility.
CORBA is a series of specifications for designing Object Request Brokers (ORBs), but it is not an actual piece of software. Many ORBs have been written to the CORBA specification, but they are all implemented differently, and not all of those ORBs suit every software project's needs. The GNOME team spent a long time searching for a suitable CORBA implementation. It required an ORB that supported C language bindings and that was both thin and fast. Eventually, a decision was made to write a CORBA ORB from scratch. Dick Porter, Elliot Lee (while working for Red Hat Labs), and Andrew Veliath wrote an all new high-performance CORBA ORB named ORBit. ORBit finally provides the plumbing that allows you to deploy CORBA throghout GNOME. It is described at http://www.labs.redhat.com/orbit.
As the GNOME system matures, new development tools are emerging to aid developers in designing GUI applications. Of particular interest is Damon Chaplin's Glade. Glade greatly simplifies the creation of complex UIs in much the same way that NeXT's Interface Builder simplifies this task under NeXTStep.
Databases can now be accessed in a uniform fashion through GNOME DB, which is a modified CORBA interface to various databases. GNOME DB also includes a designer front-end. This project is being managed by Michael Lausch, who handles the back-end and CORBA elements, and Rodrigo Moya, who is writing the GUI-builder code.
The free software community, and Unix in general, have long lacked a standard printing architecture and high-quality imaging model. GNOME provides a sophisticated printing engine intended to standardize the way applications print.
GNOME-print (http://www.levien.com/gnome/print-arch.html ) is the implementation of GNOME's printing architecture. It consists of a pluggable rendering engine and a set of standard widgets and 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 based upon the PostScript imaging model. Basic operations include vector and bezier path construction, stroking, filling, clipping, text printing (using Type1 fonts, with TrueType to follow shortly), and image printing.
At the time of this writing, GNOME-print generates only PostScript output. However, the design of the imaging model is closely linked to the rendering engine for the Canvas, and it is expected that these two modules will soon be interoperable. In particular, it will be possible to print into a Canvas, which is useful for providing a high quality print preview, and it will also be possible to print the contents of a Canvas. This feature should simplify the design of applications that use the Canvas, as very little extra code will be needed to support printing.
The GNOME-print engine will also be used to render printed pages directly without going through an intermediate PostScript step. This is especially exciting because it will allow high quality, high performance printing of complex pages to color inkjet printers. Complex pages could include transparency, gradients, and other elements considered tricky in the traditional PostScript imaging model.
|  | |
| B.4. Some GNOME Applications |  | B.6. Getting and Installing GNOME |
Copyright © 2001 O'Reilly & Associates. All rights reserved.