Common Desktop Environment: Programmer's Overview

Desktop Management

The physical metaphor associated with the Common Desktop Environment is loosely one of a user sitting in a chair surrounded by a bank of desks (workspaces). As the user swivels the chair (by clicking a push button on the Front Panel), another desk becomes accessible. On each desk, the following is available:

The user drags and drops objects to change their location and make copies of them. By dropping objects on services, the user gains assistance with appointment scheduling, editing, mail composition, printing, and so on.

Session Management

The state of the desktop can be remembered. At a later time, and perhaps at a different X display station, the state of the desktop can be re-created. A session is a snapshot of the state of a user's desktop at a point in time. The Common Desktop Environment supports two sessions from which the user can choose:

The Common Desktop Environment Session Manager coordinates these activities, but applications are responsible for saving their own state.

The desktop uses the Interclient Communication Conventions style of session management introduced in X11R5. This consists mostly of conventions for setting properties on top-level windows. The desktop extends this by providing a facility that allocates specific files into which applications can store their state. A command-line flag then points to this file when the application is restarted. Applications that maintain multiple top-level windows must save the state of each of them.

A session is associated with a particular user. In the Common Desktop Environment, the Login Manager is responsible for initial user login. The Login Manager is an alternative GUI for the UNIX login program. Normally, it checks the entered password with the user's registered password. However, vendors can provide authentication schemes tuned to their platform.

The Login Manager is network-aware. When faced with an X display that is normally served by host A, the user can log into the user's desktop by running a session from host B that has full access to the user's normal set of files and services on host B. This is possible by Login Manager acting as the desktop's X11 Display Manager (XDM). The XDM Control Protocol (XDMCP) is used between X11 window servers and XDMs on the network. The Login Manager displays its login window or host chooser window on any X11 server requesting either XDM service. This makes the Common Desktop Environment a good match for use with XDMCP-aware X terminals.

For connections to the X server, the desktop uses the X magic cookie scheme to control access. If a user on some host machine can read a certain file within a session owner's home directory, then access to the X server is granted. An alternative to this per-user authorization is per-host authorization. This is useful for installations supporting pre-X11R4 clients, which will be unable to connect to X servers using the X magic cookie scheme.

X resource files are handled in the context of Common Desktop Environment sessions as follows: a set of Common Desktop Environment default resources is merged with a host version of this file, followed by the user's $HOME/.Xdefaults file, followed by a session-specific file of resources that have changed through user interaction with the Style Manager. The result is stored in the RESOURCE_MANAGER property of the root window. To enable fine-grain customization, the C preprocessor is run on resource files.

Application Management

One of the obstacles preventing end users from taking full advantage of the network environment is the difficulty of accessing remote applications. The Common Desktop Environment provides conventions for:

The user can browse the collection of available applications with a GUI tool called Application Manager. Applications can be dragged onto the desktop for easier access. Even remote applications are started by a simple double-click, hiding the network location of a running application. The user is not aware of any distinction between local and remote applications.

This network transparency is accomplished by installing applications on network hosts designated as application servers. The parts of the installation relevant to the desktop require placing certain files in conventional places in the application's installation hierarchy. The application server maintains a list of applications that it is serving. Each host on the network maintains a list of the application servers on the network that it queries when a user logs into the desktop. This process is referred to as application gathering. It results in a dynamically-generated file hierarchy of actions arranged in folders. (Actions represent operations that end users can invoke, including starting applications.)

The Common Desktop Environment Application Manager provides a specialized view of the file system for the end user. Applications are arranged into groups and groups can be nested (such as in a directory hierarchy). Your application's installation script associates the application to a group. This association can be overridden by the system administrator as part of application server configuration. The set and arrangement of the actions shown through the Application Manager is a system resource that is typically shared between multiple users. Users cannot modify this view.

The user can drag an icon from the Application Manager onto the desktop, File Manager, Front Panel, and so on. The associated action remains valid as long as the gathered application that it refers to remains valid. Because actions represent a form of abstraction and indirection, the actual location of the application can change over time. This change remains transparent to the end user (this is explained further in "Method Invocation"). The user double-clicks on an action icon to invoke it.

Object Management

The Common Desktop Environment captures some object-oriented system attributes without being dependent upon a completely object-oriented infrastructure. The desktop provides graphic onscreen images that the user can pick up and move about, dropping them anywhere it makes semantic sense. These are viewed as objects by the user. The File Manager promotes the object abstraction by providing a graphical way to browse and modify file and directory objects within the file system. It also provides a GUI to invoke actions. When the user selects a file, the actions that are defined for the selected type of file are presented to the user.

Objects managed by desktop-based applications do not have to be file-based; in-memory buffers can represent desktop objects, too. The Common Desktop Environment Mailer handles Multipurpose Internet Mail Extensions (MIME) messages by displaying attachments to a message as icons in a scrollable panel. These are objects that behave just like file-based objects during activities such as drag and drop. The user can drag between the File Manager and the Mailer. Applications that use drag and drop should maintain this important user model by supporting both file-based and buffer-based objects. The desktop drag-and-drop API and protocol make this straightforward.

Window Management

The Window Manager is essentially the Motif window manager with extensions to provide the Front Panel GUI and workspace abstraction.

The Front Panel can be thought of as a graphic version of the root window menu supported by many window managers. It can also be thought of as a tuned object manager in which common objects are readily available to the user. The Front Panel can show dynamic system information, and it enables the user to invoke actions and system functions. The user dynamically customizes the Front Panel by dragging and dropping action icons from the Application Manager and File Manager onto subpanels. Applications can come equipped with special configuration files that extend the Front Panel, possibly defining drop behavior, drop zone animation feedback, and so on. The user can optionally install these configuration files depending on customization preferences. Figure 1-2 displays a typical desktop Front Panel.

Figure 1-2 Typical Front Panel

Graphic

Workspaces are abstractions supported by the Window Manager that can be thought of as virtual desktops. Application windows exist within one, some, or all available workspaces. The user usually determines which workspaces an application window exists in as part of the user's customization. You should rarely use the workspace API other than to explicitly designate in which workspace your application appears on session restart. In general, do not place your application within multiple workspaces, because this overrides the user's prerogative.

Style Management

The Style Manager enables users to customize their desktop using a GUI. Users are shielded from advanced concepts, such as X resources, for most common customization options. Style Manager provides controls for desktop-wide properties that adjust backdrops, keyboard settings, mouse settings, screen saver options, window management, and session management. These properties either do not affect applications directly or indirectly affect them through the X server or window manager.

You, as an application developer, are more directly influenced by font choices, color choices, and input device mappings. The Motif toolkit and the Common Desktop Environment handle many of these settings transparently for widgets. However, your application will appear more integrated with the rest of the desktop if it responds to user font and color preferences. Applications that directly interact with the mouse will feel more integrated with the rest of the desktop if they are consistent with other applications; for example, by using the same mouse button double-click minimum interval value (multiClickTime resource).

To accommodate differences between platform vendor's display technology and available font sets, the Common Desktop Environment defines font aliases that are indirect names to actual font names. Use these aliases in the same way as the rest of desktop uses them.

The Style Manager provides the user with color selection options to adjust the desktop color scheme. This color information is private to the Common Desktop Environment. Applications doing widget subclassing can indirectly access some of the color scheme by looking at inherited background pixel values. A call to XmGetColors() generates 3-D shadow colors.

The Common Desktop Environment does not dictate color usage for static colors, such as those used within icons. For these situations, however, your application should attempt to use the colors offered by the Common Desktop Environment Icon Editor, to enhance color sharing.