Table of Contents
The Gnome project was started a few years ago. The original goals (which are the same today) were:
Building a development platform for application developers,
Implement a graphical desktop on top of this framework and
Provide standard desktop applications.
This paper will focus on the first part: it will try to outline the evolution of the development platform and to present its architecture for the two main incompatible versions of Gnome, Gnome 1.x and Gnome 2.x.
If you have ever tried to write a GUI application for a UNIX platform, you probably know why a development platform is important: on UNIX, contrary to most other OSs, no graphical toolkit is standard. X, the windowing system provided with most UNIX systems provides rectangle windows in which you can draw colored graphic primitives (circles, ellipses, rectangles, lines, arrows, text). X basically handles the overlapping of windows on screen and does not enforce any policy on what the system looks like. Windows do not have what users have come to expect, that is, a simple border and title bar. It is the responsability of the window manager, a user-provided application to draw the window borders on behalf of the other applications.
One of X strengths, the fact that it does not enforce any policy, and that it does not oblige the developer to use a given toolkit is also its main weakness: in the past 10 years, many different incompatible toolkits have been developed and/or ported to X. Among these are:
GTK
XForms which derived in FLTK
QT
So, if you want to write a graphical application, you can write it to use X primitives directly, you can use GTK, QT or any other toolkit.
Once the graphical toolkit is choosen, however, you still have a long way to go to actually get a nice application which integrates nicely in the users's setup: what is normal on MacOS, win32 or BeOS, that is, the fact that all applications look and behave the same, the fact that they can be configured in the same way (think registry on win32), the fact that they have the same warning dialogs will not happen magically on UNIX. All applications use different toolkits, use a different file format for their configuration files. Among applications which use the same toolkit, some do not have the same kind of menus, aso... The main problems here are:
The fact that applications do not have the same look and feel: users get confused and the quality of the overal system feels lower even though the application's UI has been well thought out and designed.
The fact that you, as an application developer, will have to write a lot of code to accomplish common tasks such as reading and writing configuration files, creating a menu with standard items, integrating your Help into the application's dialogs...
The only reasonable way to solve these problems is to create a development platform: it is a set of libraries, of re-usable code which can be used by application writers and which guaranties that the resulting applications will all behave in sane and similar ways. It also removes a lot of the development burden from the developer by providing some common tools and functions.