CDE Infrastructure

The programming infrastructure, not the productivity tools, forms the major strength of the Common Desktop Environment. This article discusses the APIs and desktop services that benefit developers and independent software vendors.

When Project Athena at Massachusetts Institute of Technology (MIT) introduced the X Window System (X), they established the mechanism for their distributive “open” windowing protocol. Yet they intentionally left out the policy for others to develop. Later, based on technology from Hewlett-Packard (HP) and Digital Equipment Corporation, the Open Software Foundation (OSF) developed the policies of the Motif Graphical User Interface (GUI) for X. The Motif style guide established strict guidelines for its “human-centric” windowing behavior; however, the Unix desktop was still left without services such as data typing, object methods, plug and play and hypertext help.

The Unix System Laboratory licensed the Destiny Desktop with System V.4, HP developed HP Vue for HP-UX and IBM shipped IXI's X.desktop for AIX. Although these desktops provided services not offered in X and Motif GUI, they caused a divergence in the open systems market. The cost of integration and the need to remain portable kept many developers from migrating to these desktops.

CDE for Linux is offered by three major Linux distributions: Red Hat (Red Hat CDE, Don Kuenz, LJ January 1997), Xi Graphics (AcceleratedX CDE and Display Server for PC Unix, Bradley Willson, LJ November 1997) and Caldera.

The Common Desktop Environment

The Common Desktop Environment (CDE) was the result of a collaboration between HP, IBM, Sun and Novell to establish a unified open system desktop. They took the “best of breed” technology from their existing environments, then designed, implemented and delivered a new level of Unix desktop services on which developers could rely.

CDE Programming Infrastructure

CDE's Application Programming Interfaces (APIs) go beyond the basic Motif GUI. CDE provides data-typing, object methods, printing, drag and-drop, additional widgets, plug-and-play messaging and a hypertext help system. This new set of system services at the desktop level is guaranteed for all CDE-compliant systems. Developers can now more easily produce consistent applications and reduce the number of developer-specific core solutions.

Motif GUI

Motif won the open-system GUI wars; however, vendors have serviced and enhanced various releases of Motif. Although Motif became the GUI standard, portability became risky if any of the vendors' embellishments were used. Fortunately, the creators of CDE helped eliminate those problems by merging their Motif source bases to re-establish a stock GUI.

Desktop Services

CDE goes beyond the GUI to provide desktop-wide objects and methods for applications to use and call upon. Applications no longer need to depend on old and limited databases like the mime-types and mailcap that are used by applications such as mailers and web browsers.

Listing 1 shows a message dialogue program that initializes itself with the desktop and loads the desktop's data-type and method database. Then, it simply creates a message dialogue and prompts the user. When you select the E-mail button, the application calls the desktop's Compose method on the file object. The desktop spawns the mailer with the file object, where it is eventually displayed and ready to be addressed.


The desktop provides a convenient and consistent drag-and-drop API for interpreting data transfer across the desktop. Text, file names and buffers can be transferred from the dragged icon to the drop zone. The type of data being dragged determines the drag icon's appearance and configuration. Since Motif can distinguish the different types of data, applications have a more robust drag-and-drop behavior.

Desktop GUI

The desktop's DtWidget library helps bridge the current gap between CDEs in the current Motif and Motif 2.0. Developers do not need to wait for Motif 2.0 because the spin box, menu button and editor widgets are in CDE. As always, to maintain binary compatibility, developers should take special care to use XmResolvePartOffset when subclassing from one widget to make another; otherwise, an updated shared library could cause unpredictable results.