Chapter 4: The GNOME Libraries

Previously, the GNOME libraries primarily contained GTK+ extensions. However, GTK+ 2 integrated several GNOME capabilities. GNOME still contains a few widgets that serve as replacements and enhancements to GTK+ widgets, and GNOME applications attempt to use these widgets as much as possible.

To build modern graphical user interfaces, you need additional tools not directly related to user operation and graphics. The GNOME system components that provide this functionality are the subjects of the remaining chapters.

4.1 What Characterizes a GNOME Application?

A GNOME application may use these libraries:

• libgnome -2: Graphics-independent GNOME core library (Section 4.2).

• libgnomeui -2: Graphics-dependent GNOME core library (Section 4.3).

• libgnomecanvas-2: GNOME canvas widget.

• libgnomevfs-2: GNOME file access abstraction layer (see Chapter 8).

• libbonobo-2: Graphics-independent component object model (not covered in this book).

• libbonoboui-2: Graphics-dependent component object model.

• libbonobo-activation: Bonobo's object activation system.

These libraries depend on a number of other libraries, but you won't normally need to directly access these extras.

GNOME developers use the functionality in these libraries whenever possible so that they don't have to reinvent the wheel and require even more memory or libraries. GNOME applications should behave well with each other and have a consistent look and feel. You can achieve this with the following:

• Adherence to the GNOME user interface guidelines (see Section 3.1).

• Stock items for uniform icon, label, and translation appearance in buttons , menus , and tool lists whenever possible.

• Help buttons and menus to activate documentation in the ScrollKeeper database (see Section 6.4.1).

• Smooth integration with the GNOME main menu (see Section 6.3).

• Interaction with the GNOME Session Manager (see Section 4.3.16).

• Configuration with GConf (see Chapter 7).

• File access with GnomeVFS (see Chapter 8).

4.1.1 "Take This GNOME and Shove It"

Among GTK+ developers is a small but vocal minority that wants no truck with the GNOME libraries. The reasons are somewhat unclear, but the most frequent argument is that linking with GNOME causes bloat in "lean" GTK+ programs.

On the surface, this sentiment appears to have some truth, because GNOME applications usually link against more than 30 libraries. However, many of these "pure" programs wander into GNOME territory anyway. One especially absurd situation can arise when it comes to viewing HTML. For example, the mail program CscMail comes with a modified version of the GNOME GtkHtml library named CscHtml. Only the name has changed; the functionality is identical.

This sort of situation can waste even more memory because the application does not link against a popular library, and there are other possible trouble spots. Therefore, it saves memory to link against GNOME ” you should definitely think twice before coming up with your own solutions when GNOME already has one.

You may take some comfort in knowing that there aren't any plans to add more GNOME widgets. Instead, the new widgets go directly into GTK+ (and some of the old ones do, too).