Table of Contents
Table of Contents
The Gnome project was started a few years ago. The original goals (which are the same today) were:
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:
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...
Table of Contents
The Gnome 1.x platform evolved in two steps: the first releases stayed completely API and ABI compatible, without any additions. These spanned the 1.0.x and 1.2.x versions. The 1.4.x versions introduced numerous new libraries and services which are now integrated in the core Gnome 2.x releases.
Better than discussing it for ages, the diagram below describes the Gnome 1.x platform:
imlib was used as the image loading library for Gnome: GTK did not offered such services and it was felt that being able to easily load a .png or .bmp file from the hard disk onto the screen was important.
libglade was a library which could be used to create at runtime from an XML file a GUI: it would instantiate widgets on the fly and connect the application's callbacks to the relevant widget's signals.
ORBit was the CORBA implementation used in other Gnome applications: it was implemented the C mapping as defined by the specification and was used for IPC (Inter-Process-Communication). It was felt that the network transparency this system provided could allow us to create with minimum work a distributed system.
gnome-libs was the core library which put everything together: it contained useful re-usable widgets not part of GTK 1.2.x, libart, a high quality low-level vector graphics library, a canvas widget based on libart and libgnorba, a library used to instantiate CORBA applications (the equivalent of fork/exec for CORBA objects).
Gnome 1.4 was born because there was need for a transition phase between Gnome 1.0 and Gnome 2.0. We needed to develop a lot of new libraries but we also needed to make sure that these libraries would be heavily tested and used before being set in stone.
Thus, the 1.4 release contained only library additions: no feature was removed from the existing codebase and two major applications, Nautilus and Evolution, were developed with these new libraries. The diagram below shows the additions to the development platform.
The most important additions are briefly described below:
gnome-vfs provides an abstract UNIX file API: file locations are specified using urls. It alo contains the gnome mime database.
gdk-pixbuf replaces imlib: this marks finaly the end of imlib's suckyness. It provides a trivial API for image loading/resizing/displaying.
OAF replaces libgnorba: its API is similar but incompatible, its configuration files are now XML and it does not need an X server to run anymore.
GConf replaces gnome-config: it provides change notification of the configuration properties it manages. It can also have different database backends.
bonobo is one of the major additions to this release: it provides a way to create re-usable graphic controls. A la OLE/ActiveX :)
While Gnome 1.4.x is an addition release to the existing Gnome 1.x platform, Gnome 2.x is a major change:
It is the port of the whole Gnome platform from GTK 1.2.x to GTK 2.x.
It removes old cruft such as imlib and libgnorba and all the deprecated features of libgnomeui. It cleans up all the libraries' APIs, based on user feedback. It integrates the new libraries in the core of the development platform.
The above-mentioned changes introduce a number of important user-visible changes:
The font API abstraction of Pango is implemented using freetype or the new (better :) Xft or even plain X API. This means transparent antialised/hinted font display for the users.
ATK, the Accessible ToolKit, defines an API which exports accessible information to accessibility-related applications: this means that thanks to the GTK implementation of the ATK interfaces, all GTK applications become accessible.
gnome-vfs' integration means that users should be able to open files independently of their location and this is transparent to the application author.
The use of GConf to store a lot of the parameters of some widgets in libbonoboui and libgnomeui means that user changes to these preferences are dynamically applied in all the applications which use these widgets (the look of toolbars for example).