The Grand Unified Desktop

How developers and distributions can make diverse software work together better.

In December 2002, I wrote an article for
the Linux Journal web site
(www.linuxjournal.com/article/6476)
about the new Bluecurve desktop for Red Hat 8.0, which includes
programs from both GNOME and KDE. I received a lot of feedback,
including many suggestions on how to write desktop applications
that would cooperate with applications written using other toolkits
and work well in any desktop environment.

The Problem

An integrated desktop is one whose components work together,
wherever they come from, and one that never forces the end user to
do the same thing many times. The current default solutions, like
GNOME and KDE, often present limits if one tries to mix
pieces.

Communication between graphical clients, from simple
drag-and-drop to the handling of icons, menus, metadata such as
URLs and, in general, window-level interactions, work out of the
box only for some subsets of clients and window managers. The same
applies to centrally managed and good-looking fonts.

And what about localization? How many programs are still a
pain to use with a non-English language or keyboard?

KDE and GNOME are two collections of applications that seem
to solve many of these problems. But are toolkit-centric,
all-or-nothing approaches the easiest to maintain? What if somebody
creates an even better toolkit? What about applications from other
toolkits or the whole best-of-breed philosophy so natural among
free software users?

In other words, what is the best way to develop that killer
application for your favorite desktop, other people's favorite
desktops and the desktop of the future?

The Solutions

Re-inventing the wheel may be silly, but it's much less silly
than inventing a wheel that needs a new road. Consequently, even if
there already are 20 chat clients for Linux, code another one if it
feels good; however, make sure that it interoperates with what
already exists. Start with common sense, and use the right free
standards and protocols. Afterward, check that whatever toolkit or
library you choose respects them too. Many top developers already
are fully aware that this is the winning approach in the long term.
GNOME developer Havoc Pennington wrote, “Interactions between
applications and the runtime environment really need to take place
via documented, toolkit-independent protocols and file formats.”
Let's look at how to do this in practice.

File Formats

The most interesting thing in the office formats field, but
also for many other types of structured data storage, probably is
the work of the Oasis Group. The Oasis file formats are being
developed starting with the OpenOffice.org ones, so OpenOffice.org
developers will have an easier time. But every program, from Emacs
to KOffice to the next word processor, can use them.

Along these lines, there's no need to create yet another
bookmark format. XBEL (XML Bookmark Exchange Language) is a
bookmark interchange format that Galeon and Konqueror already
use.

The idea of an interchange format is valid for other
configuration files too. UNIX and Linux still are following the
toolbox approach: no mammoths, but a lot of little pieces, each
doing one thing well. One practical consequence of this is that all
the applications doing the same thing will need to know and store
the same set of parameters, or very similar ones.

Sticking to the chat client example, the really silly thing
would be to have one configuration file for Qt_chat_app, one for
GTK_chat_app, one for MyToolKit_chat_app and so on. There is a
fundamental difference between a file and the way it is created or
updated. Using different editing methods are okay (vi, a control
panel, etc.), but in the long term, what really matters is having a
single ~/.chatrc file with every existing chat client using it and
not complaining if the settings changed from another chat client.
Usenet newsreaders already use the standard .newsrc file. Until a
standard emerges for your category of application, an acceptable
compromise is to have your new program load the settings of other
similar clients when it first starts and use them as
defaults.

Guessing the MIME type of a file from its name is an action
performed looking at a MIME database. This can be unified too, so
that every desktop and program is guaranteed to read the same data;
freedesktop.org has a draft specification of how to do this.

Graphical Interfaces

Many people say that X is showing its age and point to
ambitious, far-reaching projects like Fresco. Even without aiming
so high, however, a lot can be done to make sure that any mix of
clients and window managers behave properly. A starting point for
approaching this kind of problem is the freedesktop.org site,
especially its standards section.

Remember what we just said about applications of the same
type sharing the same set of configuration parameters? We were
referring to the core functionality, but the same approach can be
used with all GUI-level settings, in all the components of your
desktop. Things like background color or the double-click timeout
are needed by all programs and still can be configured once and for
all by each user, regardless of the particular mix of toolkits he
or she needs. The X Resource Manager was not designed to be changed
interactively and merges what is written in ~/.Xdefaults with data
from other sources, so it is not the right back end for a GUI
configuration tool. Go for the Xsetting specification instead,
which is being designed to solve this and other problems.

Let's go one step further. What comes after the internal
configuration of each class of applications and the way they appear
and react to local user actions? The graphical interaction with
other applications and the window manager.

Dragging and dropping text from any window to another one
already is possible, theoretically at least, if all interested
parties follow the XDND protocol. This currently is supported not
only by GTK+ and Qt, but also by script-oriented toolkits like Tk
and Perl/Tk and by relative outsiders like FOX.

Figure 1 shows how XDND works. When an application must send
something to another one, it issues the proper toolkit call. The
toolkit sends everything, through the XDND protocol, to the other
toolkit, and the answer is passed back to the program in the same
way.

Figure 1. XDND, the Drag-and-Drop Protocol for X

The source must declare all the MIME types it supports to its
toolkit. These can be text in many formats, images or filenames.
The target must declare which formats it recognizes inside that
list. In this way, formatted text can be passed between two word
processors without losing font, color and so on. At the same time,
passing a paragraph from, say, KOffice to vi will lose formatting
but keep the text intact.

When drag-and-drop doesn't work, the problem is almost always
inside the application's XS, which didn't declare all the
MIME-types, used only custom ones or misused either the toolkit or
the protocol in some similar way. Practically speaking, it means
that bug reports must be filed against the
applications, not the toolkits or XDND.

Other interactions between X clients, or between clients and
the window manager, must follow the ICCCM (Inter-Client
Communication Conventions Manual) and the Extended Window Manager
Hints, EWMH for short, formerly known as the NetWM specification.
It should be noted that even the good old X clipboard is fully
described in the ICCCM. Detailed explanations of how to handle this
are provided by Keith Packard and Jamie Zawinski.

The second window interaction standard works on top of ICCCM.
It deals with all the window management features not specified in
its predecessor, because they started to appear after it. EWMH
originally was meant to be a replacement of what was then the GNOME
window manager specification, but it is designed correctly in that
it can be implemented and supported in any desktop environment.
GNOME 2 and KDE 3 both support EWMH, so any application conforming
to it can be expected to play nicely inside both environments or
with any of their components. Developers willing to have a more
precise, yet quick feel of what EWMH is supposed to do may want to
look at KDE's netwm.h.