|
HP OpenVMS Systems Documentation |
|
    
Common Desktop Environment: Programmer's Overview 1 Architectural OverviewContents of Chapter: 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 , "Common Desktop Environment Motif," the development environment documentation set, and the online man pages. Conceptual OverviewThe 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
Figure 1-1 Conceptual overview of Common Desktop Environment
Data Interaction GUIsThe 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 UNIXThe 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 Multiuser CollaborationWhile 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
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 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 ManagementThe 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:
Session ManagementThe 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 desktop uses the X11R5 Interclient Communication Conventions style of session management. 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 ManagementOne 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:
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 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 ManagementThe 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 ManagementThe Window Manager is essentially the Motif 1.2 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
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 ManagementThe 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 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. Motif GUI EngineThink of the Motif toolkit as the GUI engine of the desktop. This section discusses Common Desktop Environment Motif, Common Desktop Environment widgets, and alternative modes of Motif programming.Common Desktop Environment Motif ToolkitThe Common Desktop Environment Motif toolkit is Motif 1.2.3 with bug fixes, enhancements, and some new features. You must explicitly set resources to enable the new features. Functional additions include file selection box GUI modifications, different default settings of existing resources (primarily to lighten up the default border widths), color management enhancements, internationalization of error messages, and minor usability fixes (some of which have the effect of easing migration of OPEN LOOK users to the Common Desktop Environment).A drag-and-drop convenience layer has been added on top of the Motif 1.2 drag-and-drop API. In addition, the Common Desktop Environment uses the Motif 1.2 preregister drag feedback protocol. A drop site drag manager process keeps track of visible drop zones on the desktop. This data is used by a drag source client process to manage drag feedback interaction. Limited drag time validation of drop zones is followed by full validation at drop time, with snap-back-to-source animation if the drop fails. Common Desktop Environment Motif includes a GUI style guide and certification checklist that has substantially expanded on the Motif 1.2 style guide. Additions affect the input models, window management, and GUI design principles. Common Desktop Environment Motif WidgetsCommon Desktop Environment Motif provides two types of widgets that are not available in Motif 1.2.3:
GUI ShellThe Common Desktop Environment includes Desktop Korn shell, an interpreted scripting language alternative to C programming of the Motif toolkit. Desktop Korn shell includes selected frequently-used Common Desktop Environment, Xt, and Xlib APIs. You must use a compiled language to access the full power of the environment. However, you can write Desktop Korn shell scripts that participate in desktop integration activities such as drag and drop, session management, and ToolTalk messaging.If you are comfortable with shell programming, you may prefer to use Desktop Korn shell for modest programming tasks because it is:
GUI ConstructionThe easiest way to produce a Common Desktop Environment application, and perhaps the fastest, is to do almost no Motif toolkit programming at all. Use the Common Desktop Environment Application Builder, also known as App Builder, to construct the GUI control portion of your application. App Builder focuses on making default widget behavior easy to access. It does this by hiding many of the more esoteric resources that are available on most widgets. App Builder also makes it as easy to incorporate desktop integration infrastructure into your application, including drag and drop, session management, and ToolTalk messaging.App Builder maintains the user interface state in Builder Interface Language (BIL) files. A code generator takes the BIL files and produces Motif toolkit code. App Builder can also generate User Interface Language (UIL) files. As you make changes to your application's user interface, App Builder merges your custom code with the code it generates. Generated code is a good source of example code, even if you do not using App Builder to maintain your application's GUI state. In addition, nonprogrammers can use App Builder to produce an application GUI prototype. The prototype can roll forward to programmers for the production phase of development. Integration TechnologiesCommon Desktop Environment technologies discussed thus far have been directly involved with putting a GUI onto the screen. The integration technologies described in this section are underlying infrastructure, not GUI providers.Process ExecutionTo provide a network-leveraging environment, the Common Desktop Environment provides the Sub Process Control (SPC) mechanism to start, manage, and collect results from applications running on a remote host. A remote host installs an SPC daemon that serves as the remote end of a socket-based control mechanism. This control mechanism tries to maintain the illusion that the remote process is a local child to the parent process. Authentication of the user that owns the parent process is based upon the ability of the parent process to write a setuid file to the user's home directory and the ability of the child process to read the result.The SPC API and associated control programs are private to the Common Desktop Environment. Actions represent the public API for running applications remotely. Application MessagingThe ToolTalk Messaging Service is the application messaging mechanism for the Common Desktop Environment. Application messaging addresses inter-application control and cooperation for applications working on behalf of a single user. The ToolTalk session daemon is a local message-routing process whose control scope typically corresponds to that of the X server. This means that clients within a session issue requests, the ToolTalk session manager finds or starts some client within a session that is able to handle the request, and the ToolTalk session daemon tracks the request until completion.The desktop provides two standard ToolTalk protocols known as messages sets. A message set contains a number of messages that can be exchanged between a sender and a handler process. These messages are grouped together because they describe related requests and notices. The sender and recipient may be within the same process or on different hosts. Message sets have associated utility functions that allow you to concentrate on the semantics of the protocol without getting involved in the low-level messaging details. Some of the message set functions enable you to defer to default behavior with almost no work on your part. Desktop Message SetThe Desktop Message Set encompasses three areas. The first is windowing behavior. The second involves file access and short term file life cycle control. The third is specific to applications that have extension languages and is not generic enough to warrant library support.Media Message SetThe Media Message Set allows an application to be a container for arbitrary media, or to be a media player/editor that can be driven from such a container. The Media message interface allows a container application (such as Mailer or File Manager) to compose, display, edit, or print a file or buffer of an arbitrary media type, without understanding anything about the format of that media type. ToolTalk routes a container's requests to the user's preferred tool for the given media type and operation. This includes routing the request to an already-running instance of the tool if that instance can best handle the request.Data TypingThe Common Desktop Environment provides a uniform user interface to the objects contained on the desktop. To do this, the desktop has a mechanism, called data typing, to determine an object's type using a set of criteria. The criteria includes properties potentially shared by file-based and buffer-based objects such as name pattern and content pattern. Other criteria are exclusive to files, and include path-name pattern and file permissions. Associated with every desktop type is an extensible set of attributes, including icon name, name template pattern, list of actions suitable for presentation to a user, equivalent type names for other type spaces (for example, MIME type), and a textual description of this type. The actions and data-types database stores data criteria and data attributes.The Common Desktop Environment defines, and platform vendors supply, a set of desktop type definitions. Your application should augment the database with both proprietary and public data types at application installation time. Information is extracted from the actions and data-types through a Common Desktop Environment library API. The data typing API matches an object's properties with the database type criteria to determine the object's desktop type. The matching algorithm uses a set of precedence rules to resolve conflicts. The Common Desktop Environment type space is defined by the X/Open Common Desktop Environment standard and exists primarily to support desktop-oriented activities such as icon display and action association. The MIME type space is defined by the Internet Engineering Task Force and exists to deal with exchange of mail message parts. A ToolTalk media type space exists in order to match data with handlers, and is a subset of X selection target types defined by the X Consortium. Thus, to do a complete job of type definition, you have to define a Common Desktop Environment type, X selection target, and MIME type. For private Common Desktop Environment types, append the type name to an organization's name. This partitions the name space without need for centralized allocation of types. The Common Desktop Environment claims the Dt prefix, for Desktop. Method InvocationA Common Desktop Environment type can be thought of as the class of a desktop object. Using this analogy, actions can be thought of as the methods available on instances of a class. Thus, the actions attribute in a type attribute list describes operations that are available for the type. A single action in the actions and data-types database has multiple parts, many of which are optional. These parts include:
The actions and data-types database and the File Manager use action files to instantiate actions as file system objects that can be viewed, invoked, moved, copied, and so on. The database contains references to an action's implementation (for example "run /usr/bin/app on machine net_app_svr"). However, a representation is needed of an action as an object that the user can directly manipulate. This is achieved by using an object's name, which identifies it as an action to any object manager that is looking for actions. Thus, if there is an executable file named Dtstyle and an action named Dtstyle, the File Manager will interpret that file, regardless of its content, as the Dtstyle action reference. In addition, the File Manager uses the action's label as the name that the user sees for this file. Action labels are localizable, whereas action names are programmatic entities that should not be localized. The good feature about using files simply as pointers into the actions and data-types database is that the underlying implementation can evolve without the user having to do anything. However, one user's actions and data-types database may not match another user's actions and data-types database. Thus, a user cannot exchange an action reference, for example as a mail message attachment, and expect another person to have a comparable definition for that action. Exchanging a Desktop Korn shell script is the best solution to this problem. Actions are useful because they integrate both legacy command-line applications and ToolTalk applications into the desktop as polymorphic, distributed operations on desktop objects.
|
