Architectural Overview

This chapter presents a high-level architectural view of the Common Desktop Environment. For details regarding the desktop run-time environment, consult the run-time documentation set and the online help volumes. For details regarding the desktop development environment components, see Chapter 6, Recommended Integration, Chapter 7, Optional Integration, Appendix A, Common Desktop Environment Motif, the development environment documentation set, and the online man pages.

• Conceptual Overview

• Data Interaction GUIs

• Multiuser Collaboration

• Desktop Management

• Motif GUI Engine

• Integration Technologies

Conceptual Overview

The Common Desktop Environment architecture has many cross-process relationships. The three-process relationship of an X client, a window manager, and the X Window System™ server seems simple by comparison. The area covered by the Common Desktop Environment is broad, but the layering in the system is not as rigorous as that of Motif, Xt, and Xlib. The relationships between high-level system components are diverse and extensible. This chapter groups the technologies to illustrate that each desktop component fits into an overall whole. The Common Desktop Environment can be divided into:

Figure 1-1 Conceptual overview of Common Desktop Environment

• Data interaction graphical user interfaces (GUIs)--Application-level components that are available for user interaction, which other applications can invoke. Think of these as programming components at a larger granularity than widgets.

• Multiuser collaboration--Defines and uses application program interfaces (APIs) that enable collaboration between users on the network, particularly in the areas of calendar management, network resource naming, and network file sharing.

• Desktop management--Provides components that negotiate the visual relationships between entities on the desktop. These include the following: Window Manager, Workspace Manager, Session Manager, Application Manager, File Manager, Style Manager, and the Front Panel.

• Motif GUI engine--Includes those components that implement the controls available to the user and includes the Common Desktop Environment Motif toolkit, additional widgets, a GUI shell (Desktop Korn shell), and a GUI construction tool (Application Builder).

• Integration technologies--Represent technologies that do not generate GUIs, but are used as infrastructure by the rest of the desktop. These technologies include process execution control, application messaging (mechanism and protocols), data typing, and method invocation.

Data Interaction GUIs

The Common Desktop Environment supplies a registration service, the ToolTalk Messaging Service, that enables an application to find an available service provider. ToolTalk provides the low-level messaging infrastructure. A companion mechanism, called the actions system, provides a consistent abstraction layer on top of both the traditional UNIX™ command-line interface to applications and the Common Desktop Environment-recommended ToolTalk interface to applications. Actions, as semantic entities, are exposed to the end user through higher levels of software. Both actions and ToolTalk are discussed in more detail in Integration Technologies .

The desktop contains components that are available through action and ToolTalk APIs. Examples include GUIs to show a view of a directory, submit a print job, view the contents of the Trash Can, edit some text, show help information, compose a calendar appointment, and compose a mail message.

You can also incorporate actions and ToolTalk message support into your application so that the application-specific services they supply are available to the desktop and other applications. Particularly, applications should provide the composition, viewing, editing, and printing services for both proprietary and standard format data. This way, applications that are coded to accept an extensible set of data types automatically gain more capabilities as more media handlers are added to the system. The Common Desktop Environment File Manager, Front Panel, and Mailer attachment GUI are examples of such applications.

Media is used as a generic term for anything that can be presented to the user to convey information. The desktop provides media handlers for appointments, mail messages, mail folders, text, icons, and help data. Vendors have extended the desktop with additional media handlers, including PostScript™, many kinds of image file formats, and audio data.

Multiuser Collaboration

While the ToolTalk and action mechanisms encourage cooperation between applications, the desktop also defines cross-user collaboration technologies. This means distributed access to shared user data. The desktop has defined some basic sharing mechanisms and has also built on top of existing mechanisms.

An example of building on an existing mechanism is the remote procedure call (RPC) client/service implementation of calendar management. The desktop provides a client-side library and API, RPC protocol, and daemon/service that enables users to share appointment information. (The API is being standardized through X.400 Application Programming Interface Association (XAPIA) to enable a cross-UNIX, PC, and palmtop calendar standard.) The RPC protocol enables a user to browse and directly edit another user's calendar. Access is controlled by a user-specific access control mechanism. Calendars are tied to hosts, and a calendar's data is maintained by a host-specific daemon. The desktop names calendars through a user@host format.

The Common Desktop Environment uses conventional distributed file systems to name files that are sharable on the network. To provide an interface that is independent of the distributed file system, the desktop provides an API to translate host-relative file names into locally expressible file names. Although the desktop is based on the NFS™ system, it can be ported to run on top of other distributed file systems. Using the desktop file-name mapping API, an opaque file name object can be constructed and passed between desktop clients across the network and resolved in a host-specific way. Also, to simplify the programming task and end user metaphor, Common Desktop Environment applications should present remote file references as local file paths.

One of the fundamentals of building multiuser collaboration applications is the ability to share files. The conventions for naming network files, in conjunction with a ToolTalk file-sharing mechanism called file scoping, enable multiuser collaboration through file sharing. File scoping is more than a mechanism for simple, exclusive access control. Cooperating clients can use file-scope access to negotiate for access to files. For example, an application that has exclusive access to a file could ask whether the user was done with the file when another application wanted to gain exclusive access to the file.

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:

• A collection of drawers (File Manager views) in which folders (directories) and reports (files) are organized.

• A collection of papers in use on the desktop (windows). Some papers are pushed out of the way (as icons), but are within easy reach.

• Continuous display (through Front Panel icons) of a clock, the date, an indication of new mail, and an indication of something in the trash can.

• Direct access (through Front Panel buttons) to an appointment book (Calendar), an address book (Address Manager), a pad of paper (Text Editor), a mail box (Mail), a printer (Personal Printers), office lighting controls (Desktop Style), a guide book (Help Manager), and a window to the outside world (Links).

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:

• Home session--A snapshot of the desktop state that reassembles in the same way each time it is started.

• Current session--The state of a desktop saved at logout time.

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:

• Installation of applications so that they can be run remotely

• User navigation of available applications

• Execution of remote applications

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.