759 lines
49 KiB
Plaintext
759 lines
49 KiB
Plaintext
<!-- $XConsortium: ch01.sgm /main/13 1996/10/30 14:58:57 rws $ -->
|
|
<!-- (c) Copyright 1995 Digital Equipment Corporation. -->
|
|
<!-- (c) Copyright 1995 Hewlett-Packard Company. -->
|
|
<!-- (c) Copyright 1995 International Business Machines Corp. -->
|
|
<!-- (c) Copyright 1995 Sun Microsystems, Inc. -->
|
|
<!-- (c) Copyright 1995 Novell, Inc. -->
|
|
<!-- (c) Copyright 1995 FUJITSU LIMITED. -->
|
|
<!-- (c) Copyright 1995 Hitachi. -->
|
|
|
|
<chapter id="RDMAP.archo.div.1">
|
|
<title id="RDMAP.archo.mkr.1">Architectural Overview</title>
|
|
<para>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
|
|
<!--Original
|
|
XRef content: 'Chapter 6, &xd2;Recommended Integration'--><xref role="ChapNumAndTitle"
|
|
linkend="RDMAP.recin.mkr.1">, <!--Original XRef content: 'Chapter 7,
|
|
&xd2;Optional Integration'--><xref role="ChapNumAndTitle" linkend="RDMAP.optin.mkr.1">,
|
|
the development environment documentation set, and the online man pages.
|
|
</para>
|
|
<informaltable id="RDMAP.archo.itbl.1" frame="All">
|
|
<tgroup cols="1">
|
|
<colspec colname="1" colwidth="4.0 in">
|
|
<tbody>
|
|
<row rowsep="1">
|
|
<entry><para><!--Original XRef content: 'Conceptual Overview3'--><xref role="JumpText"
|
|
linkend="RDMAP.archo.mkr.2"></para></entry></row>
|
|
<row rowsep="1">
|
|
<entry><para><!--Original XRef content: 'Data Interaction GUIs5'--><xref role="JumpText"
|
|
linkend="RDMAP.archo.mkr.3"></para></entry></row>
|
|
<row rowsep="1">
|
|
<entry><para><!--Original XRef content: 'Multiuser Collaboration6'--><xref
|
|
role="JumpText" linkend="RDMAP.archo.mkr.4"></para></entry></row>
|
|
<row rowsep="1">
|
|
<entry><para><!--Original XRef content: 'Desktop Management7'--><xref role="JumpText"
|
|
linkend="RDMAP.archo.mkr.5"></para></entry></row>
|
|
<row rowsep="1">
|
|
<entry><para><!--Original XRef content: 'Motif GUI Engine12'--><xref role="JumpText"
|
|
linkend="RDMAP.archo.mkr.7"></para></entry></row>
|
|
<row rowsep="1">
|
|
<entry><para><!--Original XRef content: 'Integration Technologies15'--><xref
|
|
role="JumpText" linkend="RDMAP.archo.mkr.8"></para></entry></row>
|
|
<row rowsep="1">
|
|
<entry><para>Information Technologies ??
|
|
</para></entry></row>
|
|
</tbody>
|
|
</tgroup></informaltable>
|
|
<sect1 id="RDMAP.archo.div.2">
|
|
<title id="RDMAP.archo.mkr.2">Conceptual Overview</title>
|
|
<para>The Common Desktop Environment<indexterm><primary>architecture, Common
|
|
Desktop Environment</primary></indexterm> 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<indexterm><primary>Motif</primary>
|
|
</indexterm> 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:</para>
|
|
<figure>
|
|
<title>Conceptual overview of Common Desktop Environment</title>
|
|
<graphic id="rdmap.archo.igrph.1" entityref="RDMAP.archo.fig.1"></graphic>
|
|
</figure>
|
|
<itemizedlist remap="Bullet1"><listitem><para>Data interaction graphical user
|
|
interfaces (GUIs)—Application-level components that are available for
|
|
user interaction, invocable by other applications. Think of these as programming
|
|
components at a larger granularity than widgets.<indexterm><primary>data
|
|
interaction graphical user interfaces</primary></indexterm></para>
|
|
</listitem><listitem><para>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.<indexterm><primary>multiuser collaboration</primary></indexterm></para>
|
|
</listitem><listitem><para>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.<indexterm>
|
|
<primary>desktop management</primary></indexterm></para>
|
|
</listitem><listitem><para>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
|
|
KornShell), and a GUI construction tool (Application Builder).<indexterm>
|
|
<primary>graphical user interface engine</primary></indexterm></para>
|
|
</listitem><listitem><para>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.<indexterm>
|
|
<primary>integration technologies</primary></indexterm></para>
|
|
</listitem></itemizedlist>
|
|
</sect1>
|
|
<sect1 id="RDMAP.archo.div.3">
|
|
<title id="RDMAP.archo.mkr.3">Data Interaction GUIs<indexterm><primary>data
|
|
interaction graphical user interfaces <$startrange></primary></indexterm></title>
|
|
<para>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<indexterm><primary>UNIX</primary></indexterm> 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 <!--Original XRef content: '&xd2;Integration Technologies&xd3; on page 15'--><xref
|
|
role="SecTitleAndPageNum" linkend="RDMAP.archo.mkr.8">.</para>
|
|
<para>The desktop contains components that are available through<indexterm>
|
|
<primary>actions</primary></indexterm> 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.</para>
|
|
<para>You can also incorporate actions and<indexterm><primary>ToolTalk Messaging
|
|
Service</primary></indexterm> 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 <emphasis>media</emphasis> handlers are added to the system. The Common Desktop Environment<indexterm><primary>File Manager</primary></indexterm>
|
|
File Manager,<indexterm>
|
|
<primary>Front Panel</primary></indexterm> Front Panel, and<indexterm><primary>Mailer</primary></indexterm> Mailer attachment GUI are examples of such applications.
|
|
</para>
|
|
<para>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 <literal><indexterm><primary>data interaction graphical user interfaces <$endrange></primary></indexterm></literal>data.</para>
|
|
</sect1>
|
|
<sect1 id="RDMAP.archo.div.4">
|
|
<title id="RDMAP.archo.mkr.4">Multiuser Collaboration<indexterm><primary>multiuser collaboration <$startrange></primary></indexterm></title>
|
|
<para>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.
|
|
</para>
|
|
<para>An example of building on an existing mechanism is the<indexterm>
|
|
<primary>remote procedure call (RPC)</primary></indexterm> 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<indexterm><primary>X.400 API Association (XAPIA)</primary></indexterm> 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 <computeroutput>user@host</computeroutput> format.</para>
|
|
<para>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.</para>
|
|
<para>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 <emphasis><indexterm>
|
|
<primary>file scoping</primary></indexterm>file scoping</emphasis>, 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.<literal><indexterm>
|
|
<primary>multiuser collaboration <$endrange></primary></indexterm></literal></para>
|
|
</sect1>
|
|
<sect1 id="RDMAP.archo.div.5">
|
|
<title id="RDMAP.archo.mkr.5">Desktop Management</title>
|
|
<para>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:</para>
|
|
<itemizedlist remap="Bullet1"><listitem><para>A collection of drawers (<indexterm>
|
|
<primary>File Manager</primary></indexterm> File Manager views) in which folders
|
|
(directories) and reports (files) are organized.</para>
|
|
</listitem><listitem><para>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.
|
|
</para>
|
|
</listitem><listitem><para>Continuous display (through<indexterm><primary>Front Panel</primary></indexterm> Front Panel icons) of a clock, the date,
|
|
an indication of new mail, and an indication of something in the trash can.
|
|
</para>
|
|
</listitem><listitem><para>Direct access (through Front Panel buttons) to
|
|
an appointment book (<indexterm><primary>Calendar</primary></indexterm>Calendar),
|
|
a pad of paper (<indexterm><primary>Text Editor</primary></indexterm>Text
|
|
Editor), a terminal (emulator), a mail box (<indexterm><primary>Mailer</primary>
|
|
</indexterm>Mailer), a printer (<indexterm><primary>Print Manager</primary>
|
|
</indexterm>Print Manager), office lighting controls (<indexterm><primary>Style Manager</primary></indexterm>Style Manager), a list of electronic agents
|
|
(<indexterm><primary>Application Manager</primary></indexterm>Application
|
|
Manager and Front Panel personal tool box), a guide book (<indexterm>
|
|
<primary>Help system</primary></indexterm>Help), and a library (Information
|
|
Manager).</para>
|
|
</listitem></itemizedlist>
|
|
<para>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 other tasks.</para>
|
|
<sect2 id="RDMAP.archo.div.6">
|
|
<title>Session Management<indexterm><primary>desktop management</primary>
|
|
<secondary>session management <$startrange></secondary></indexterm><indexterm><primary>Session Manager <$startrange></primary></indexterm></title>
|
|
<para>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 the following sessions from which the user
|
|
can choose at login:</para>
|
|
<itemizedlist remap="Bullet1"><listitem><para>Home session—A snapshot
|
|
of the desktop state that reassembles in the same way each time it is started.
|
|
</para>
|
|
</listitem><listitem><para>Current session—The state of a desktop saved
|
|
at logout time.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Display-specific Home session—A Home session created by the user for a specific display;
|
|
if it exists, it takes precedence over the generic Home session.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Display-specific Current session—A Current session created by the user for a specific
|
|
display; if it exists, it takes precedence over the generic Current session.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Failsafe session—A minimal session that can be used to access the system if the normal
|
|
<command>login</command> fails.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>The Common Desktop Environment Session Manager coordinates these activities,
|
|
but applications are responsible for saving their own state.</para>
|
|
<para>The desktop supports the X11R6 X Session Management Protocol and
|
|
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.</para>
|
|
<para>A session is associated with a particular user. In the Common Desktop
|
|
Environment, the Login Manager is responsible for initial user login. The<indexterm><primary>Login Manager</primary></indexterm>
|
|
Login Manager is
|
|
an alternative GUI for the<indexterm><primary>UNIX</primary></indexterm> 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.</para>
|
|
<para>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<indexterm><primary>X11 Display Manager (XDM)</primary>
|
|
</indexterm> 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.</para>
|
|
<para>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<indexterm><primary>X magic
|
|
cookie scheme</primary></indexterm> X magic cookie scheme.</para>
|
|
<para>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 <filename>$HOME/.Xdefaults</filename> 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 <filename>RESOURCE_MANAGER</filename> property of the root
|
|
window. To enable fine- grain customization, the C preprocessor is run on
|
|
resource files.<literal><indexterm><primary>desktop management</primary><secondary>session management <$endrange></secondary></indexterm><indexterm><primary>Session Manager <$endrange></primary></indexterm></literal>
|
|
</para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.7">
|
|
<title>Application Management<indexterm><primary>desktop management</primary>
|
|
<secondary>application management <$startrange></secondary></indexterm></title>
|
|
<para>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:</para>
|
|
<itemizedlist remap="Bullet1"><listitem><para>Installation of applications
|
|
so that they can be run remotely</para>
|
|
</listitem><listitem><para>User navigation of available applications</para>
|
|
</listitem><listitem><para>Execution of remote applications</para>
|
|
</listitem></itemizedlist>
|
|
<para>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.</para>
|
|
<para>This network transparency is accomplished by installing applications
|
|
on network hosts designated as <emphasis><indexterm><primary>application
|
|
servers</primary></indexterm>application servers</emphasis>. 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 <emphasis>application gathering</emphasis>. It results in a dynamically-generated
|
|
file hierarchy of actions arranged in folders. (Actions represent operations
|
|
that end users can invoke, including starting applications.<indexterm><primary>actions</primary></indexterm>)</para>
|
|
<para>The Common Desktop Environment<indexterm><primary>Application Manager</primary></indexterm> 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.</para>
|
|
<para>The user can drag an icon from the<indexterm><primary>Application
|
|
Manager</primary></indexterm> 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 <!--Original XRef content: '&xd2;Method Invocation&xd3;
|
|
on page 18'--><xref role="SecTitleAndPageNum" linkend="RDMAP.archo.mkr.9">).
|
|
The user double-clicks on an action icon to invoke it.<indexterm>
|
|
<primary>desktop management</primary><secondary>application management <$endrange></secondary></indexterm></para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.8">
|
|
<title>Object Management</title>
|
|
<para>T<literal><indexterm><primary>desktop management</primary><secondary>object management</secondary></indexterm><indexterm><primary>object management</primary></indexterm></literal>he 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 <symbol role="Variable">objects</symbol>
|
|
by the user. The<indexterm><primary>File Manager</primary></indexterm> 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.</para>
|
|
<para>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<indexterm><primary>Multipurpose Internet Mail
|
|
Extensions (MIME)</primary></indexterm> 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<indexterm><primary>Mailer</primary></indexterm> 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.</para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.9">
|
|
<title>Window Management</title>
|
|
<para>The <literal><indexterm><primary>desktop management</primary><secondary>window management</secondary></indexterm><indexterm><primary>Window Manager <$startrange></primary></indexterm></literal>Window
|
|
Manager is essentially the Motif window manager with extensions to provide
|
|
the<indexterm><primary>Front Panel</primary></indexterm> Front Panel GUI
|
|
and workspace abstraction.</para>
|
|
<para>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<indexterm><primary>Application Manager</primary></indexterm> Application Manager and<indexterm>
|
|
<primary>File Manager</primary></indexterm> 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. <!--Original XRef content: 'Figure 1‐2'--><xref
|
|
role="CodeOrFigureOrTable" linkend="RDMAP.archo.mkr.6"> displays a typical
|
|
desktop Front Panel.</para>
|
|
<figure>
|
|
<title id="RDMAP.archo.mkr.6">Typical Front Panel</title>
|
|
<graphic id="RDMAP.archo.grph.1" entityref="RDMAP.archo.fig.2"></graphic>
|
|
</figure>
|
|
<para>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.<indexterm><primary>desktop management</primary><secondary>window management</secondary></indexterm><indexterm>
|
|
<primary>Window Manager <$endrange></primary></indexterm></para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.10">
|
|
<title>Style Management</title>
|
|
<para>The <literal><indexterm><primary>desktop management</primary><secondary>style management</secondary></indexterm><indexterm><primary>Style Manager <$startrange></primary></indexterm></literal>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.</para>
|
|
<para>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 ( <command>multiClickTime</command> resource).</para>
|
|
<para>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.</para>
|
|
<para>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 <computeroutput>XmGetColors()</computeroutput> generates
|
|
3-D shadow colors.</para>
|
|
<para>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.<indexterm>
|
|
<primary>desktop management</primary><secondary>style management</secondary>
|
|
</indexterm><indexterm><primary>Style Manager <$endrange></primary></indexterm></para>
|
|
</sect2>
|
|
</sect1>
|
|
<sect1 id="RDMAP.archo.div.11">
|
|
<title id="RDMAP.archo.mkr.7">Motif GUI Engine</title>
|
|
<para>Think 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.</para>
|
|
<sect2 id="RDMAP.archo.div.12">
|
|
<title>Common Desktop Environment Motif Toolkit</title>
|
|
<para>The<indexterm><primary>graphical user interface engine</primary><secondary>Common Desktop Environment Motif Toolkit</secondary></indexterm><indexterm>
|
|
<primary>Common Desktop Environment Motif <$startrange></primary></indexterm> 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<indexterm><primary>OPEN LOOK</primary></indexterm> OPEN LOOK users to
|
|
the Common Desktop Environment).</para>
|
|
<para>Common Desktop Environment Motif and<indexterm><primary>Motif 2.0</primary></indexterm> Motif 2.0 are also highly compatible. Most functions
|
|
put into Common Desktop Environment Motif have been introduced into Motif
|
|
2.0. As a result, developers have compiled their applications with Common
|
|
Desktop Environment Motif, relinked to Motif 2.0, and ran the applications
|
|
successfully. Widget subclassing that has not followed Motif 1.2 subclassing
|
|
guidelines designed to shield programs from widget size changes are likely
|
|
to fail.</para>
|
|
<para>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 <emphasis>snap- back-to-source</emphasis> animation if the drop fails.
|
|
</para>
|
|
<para>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.<indexterm>
|
|
<primary>graphical user interface engine</primary><secondary>Common Desktop
|
|
Environment Motif Toolkit</secondary></indexterm><indexterm><primary>Common
|
|
Desktop Environment Motif <$endrange></primary></indexterm></para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.13">
|
|
<title>Common Desktop Environment Motif Widgets</title>
|
|
<para><indexterm><primary>graphical user interface engine</primary><secondary>Common Desktop Environment Motif widgets</secondary></indexterm><indexterm>
|
|
<primary>Common Desktop Environment widgets</primary></indexterm>Common Desktop
|
|
Environment Motif provides two types of widgets that are not available in
|
|
Motif 1.2.3:</para>
|
|
<itemizedlist remap="Bullet1"><listitem><para>Low-level control widgets:
|
|
</para>
|
|
<itemizedlist remap="Bullet2"><listitem><para>SpinBox—A text field and
|
|
arrow button widget</para>
|
|
</listitem><listitem><para>ComboBox—A text field and list box widget
|
|
</para>
|
|
</listitem><listitem><para>MenuButton—A menu that doesn't need to be
|
|
in a row column widget</para>
|
|
</listitem></itemizedlist>
|
|
<para>These were added primarily to help you port applications from a Microsoft®
|
|
Windows or OPEN LOOK environment. The SpinBox and ComboBox widgets have equivalents
|
|
in Motif 2.0.</para>
|
|
</listitem><listitem><para>Rich and full-featured widgets:</para>
|
|
<itemizedlist remap="Bullet2"><listitem><para>Terminal Emulator widget—Useful
|
|
for applications designed to mix the best of a command-line user interface
|
|
with a GUI</para>
|
|
</listitem><listitem><para>Editor widget—Available for embedding a more
|
|
full-featured plain text editor than that available from the Motif Text widget
|
|
</para>
|
|
</listitem><listitem><para>Help widgets—Handle navigation and interaction
|
|
with application help volumes</para>
|
|
<para>Help is delivered with an application in the form of<indexterm><primary>Semantic Description Language (SDL)</primary></indexterm> Semantic Description
|
|
Language (SDL) files that have been compiled from <emphasis><indexterm><primary>HelpTag</primary></indexterm>HelpTag</emphasis>, a form of<indexterm><primary>Standard Generalized Markup Language (SGML)</primary></indexterm> Standard
|
|
Generalized Markup Language (SGML) files. The Help system features mixed
|
|
text and graphics, hyper links, dynamic reformatting of text, and structured
|
|
navigation capabilities.</para>
|
|
</listitem></itemizedlist>
|
|
</listitem></itemizedlist>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.14">
|
|
<title>GUI Shell</title>
|
|
<para>The<indexterm><primary>graphical user interface engine</primary><secondary>Desktop KornShell</secondary></indexterm><indexterm><primary>Desktop KornShell
|
|
(dtksh) <$startrange></primary>
|
|
</indexterm> Common Desktop Environment includes Desktop KornShell, an interpreted
|
|
scripting language alternative to C programming of the Motif toolkit. Desktop
|
|
KornShell 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 KornShell scripts that
|
|
participate in desktop integration activities such as drag and drop, session
|
|
management, and ToolTalk messaging.</para>
|
|
<para>If you are comfortable with shell programming, you may prefer to use
|
|
Desktop KornShell for modest programming tasks because it is:</para>
|
|
<itemizedlist remap="Bullet1"><listitem><para>Well suited to system-administration-type
|
|
applications because the shell commands intermix easily with GUI control.
|
|
</para>
|
|
</listitem><listitem><para>Good for putting a GUI control program on top of
|
|
character-based applications because the shell environment handles character-based
|
|
interaction in a natural way.</para>
|
|
</listitem><listitem><para>A good way to deliver instruction-set-independent
|
|
programs to a heterogeneous collection of hosts. For example, use the Common
|
|
Desktop Environment<indexterm><primary>Mailer</primary></indexterm> Mailer
|
|
to attach a script to a message that the recipient simply double-clicks to
|
|
invoke.<indexterm><primary>graphical user interface engine</primary><secondary>Desktop KornShell</secondary></indexterm><indexterm><primary>Desktop KornShell
|
|
(dtksh) <$endrange></primary>
|
|
</indexterm></para>
|
|
</listitem></itemizedlist>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.15">
|
|
<title>GUI Construction</title>
|
|
<para>The<indexterm><primary>graphical user interface engine</primary><secondary>Application Builder</secondary></indexterm><indexterm><primary>Application
|
|
Builder <$startrange></primary>
|
|
</indexterm> 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.</para>
|
|
<para>App Builder maintains the user interface state in<indexterm><primary>Builder Interface Language (BIL)</primary></indexterm> Builder Interface Language
|
|
(BIL) files. A code generator takes the BIL files and produces Motif toolkit
|
|
code. App Builder can also generate<indexterm><primary>User Interface Language
|
|
(UIL)</primary></indexterm> User Interface Language (UIL) files.</para>
|
|
<para>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.</para>
|
|
<para>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.<indexterm><primary>graphical user interface engine</primary><secondary>Application Builder</secondary></indexterm><indexterm>
|
|
<primary>Application Builder <$endrange></primary></indexterm></para>
|
|
</sect2>
|
|
</sect1>
|
|
<sect1 id="RDMAP.archo.div.16">
|
|
<title id="RDMAP.archo.mkr.8">Integration Technologies</title>
|
|
<para>Common 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.
|
|
</para>
|
|
<sect2 id="RDMAP.archo.div.17">
|
|
<title>Process Execution<indexterm><primary>integration technologies</primary>
|
|
<secondary>process execution</secondary></indexterm><indexterm><primary>process
|
|
execution</primary></indexterm></title>
|
|
<para>To provide a network-leveraging environment, the Common Desktop Environment
|
|
provides the<indexterm><primary>Sub Process Control (SPC)</primary></indexterm> 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 <symbol role="Variable">child</symbol> to the <symbol role="Variable">parent</symbol>
|
|
process. Authentication of the user that owns the parent process is based
|
|
upon the ability of the parent process to write a <command>setuid</command>
|
|
file to the user's home directory <emphasis>and</emphasis> the ability of
|
|
the child process to read the result.</para>
|
|
<para>The SPC API and associated control programs are private to the Common
|
|
Desktop Environment. Actions represent the public API for running applications
|
|
remotely.</para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.18">
|
|
<title>Application Messaging<indexterm><primary>integration technologies</primary>
|
|
<secondary>application messaging</secondary></indexterm><indexterm><primary>ToolTalk Messaging Service <$startrange></primary></indexterm></title>
|
|
<para>The 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.</para>
|
|
<para>The desktop provides two standard ToolTalk protocols known as <emphasis>messages sets</emphasis>. 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.</para>
|
|
<sect3 id="RDMAP.archo.div.19">
|
|
<title>Desktop Message Set</title>
|
|
<para>The 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.</para>
|
|
</sect3>
|
|
<sect3 id="RDMAP.archo.div.20">
|
|
<title>Media Message Set</title>
|
|
<para>The 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<indexterm>
|
|
<primary>Mailer</primary></indexterm> Mailer or<indexterm><primary>File Manager</primary></indexterm> 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.<indexterm>
|
|
<primary>integration technologies</primary><secondary>application messaging</secondary></indexterm><indexterm><primary>ToolTalk Messaging Service <$endrange></primary></indexterm></para>
|
|
</sect3>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.21">
|
|
<title>Data Typing<indexterm><primary>data typing <$startrange></primary></indexterm></title>
|
|
<para>The 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 <emphasis>actions and data-types
|
|
database</emphasis> stores data criteria and data attributes.</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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 <emphasis>Dt</emphasis> prefix, for <emphasis>Desktop</emphasis>.<indexterm>
|
|
<primary>data typing <$endrange></primary></indexterm></para>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.22">
|
|
<title id="RDMAP.archo.mkr.9">Method Invocation<indexterm><primary>actions <$startrange></primary></indexterm></title>
|
|
<para>A 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<indexterm>
|
|
<primary>methods, and actions</primary></indexterm> 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:</para>
|
|
<itemizedlist remap="Bullet1"><listitem><para>A description of how to invoke
|
|
the operation: for example, through ToolTalk, through an execution string
|
|
passed to the SPC mechanism, from within a terminal emulator, and so on.
|
|
</para>
|
|
</listitem><listitem><para>A description of the type of arguments associated
|
|
with the action. The type of the desktop objects (files and buffers) that
|
|
it accepts is defined by the actions and data-types database. Actions are
|
|
polymorphic with respect to data types. For example, the Open action invokes
|
|
a text editor for arguments that are text files and a graphics editor for
|
|
arguments that are graphics files.</para>
|
|
</listitem><listitem><para>A description of the number of arguments, if any,
|
|
associated with the action.</para>
|
|
</listitem><listitem><para>An optional indication as to where to carry out
|
|
the operation: the local machine, a particular remote machine, the machine
|
|
on which the executable resides, and so on. In addition, these execution
|
|
locations can be included in a list so that if a host is not available then
|
|
the next host on the list is tried. This provides a measure of redundancy
|
|
that can be used to increase the likelihood of application launch, even in
|
|
the face of remote host unavailability. Thus, actions provide network distribution
|
|
guidance, implemented either through built-in ToolTalk facilities or through
|
|
the SPC mechanism directly.</para>
|
|
</listitem><listitem><para>An optional label, help string, and icon that the
|
|
user sees when interacting with the action's GUI. These are hints to an application
|
|
about how to represent the action to the user. These hints may be ignored,
|
|
as the Front Panel does by ignoring the icon if the Front Panel configuration
|
|
file supplies an alternative icon.</para>
|
|
</listitem></itemizedlist>
|
|
<para>The collection of actions available to the user is assembled at the
|
|
same time as the system is collecting type database information. In fact,
|
|
related action and type information usually reside together in the same file.
|
|
Desktop-defined, system-administrator-defined (host-specific), and user-defined
|
|
files are assembled in order into a single (actions and data-types) database,
|
|
with later definitions taking precedence. This ordering of search path precedence
|
|
and traversal is used elsewhere by the desktop for such things as help volume
|
|
and icon file searches.</para>
|
|
<para>The actions and data-types<indexterm><primary>database</primary></indexterm> 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 <filename>/usr/bin/app</filename> on machine <filename>net_app_svr</filename>”).
|
|
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 <command>Dtstyle</command> 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.</para>
|
|
<para>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 KornShell script is the best solution to
|
|
this problem.</para>
|
|
<para>Actions are useful because they integrate both legacy command-line
|
|
applications and ToolTalk applications into the desktop as polymorphic, distributed
|
|
operations on desktop objects.<literal><indexterm><primary>actions <$endrange></primary>
|
|
</indexterm></literal></para>
|
|
</sect2>
|
|
</sect1>
|
|
<sect1 id="RDMAP.archo.div.23">
|
|
<title id="RDMAP.archo.mkr.10">Information Technologies</title>
|
|
<para>CDE information technologies comprise
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The Help system, which provides help on the CDE user interface, and potentially,
|
|
the help you provide for your CDE applications.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The Information Manager, an on-line documentation access facility
|
|
that provides access to CDE documentation, and potentially, your application-specific documentation.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<sect2 id="RDMAP.archo.div.24">
|
|
<title id="RDMAP.archo.mkr.11">Help System</title>
|
|
<indexterm><primary>help</primary><secondary>general information</secondary></indexterm>
|
|
<para>The Help system provides a complete set of authoring and programming
|
|
tools to develop on-line help for CDE applications:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>It enables authors to include formatted text, graphics, hyperlinks, and communication
|
|
with the application.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>It provides programmers with a toolkit for integrating on-line
|
|
help into an application. The toolkit includes specialized Help dialogs and supporting
|
|
routines that enable users to display, navigate, search, and print on-line help.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
<sect2 id="RDMAP.archo.div.25">
|
|
<title id="RDMAP.archo.mkr.12">Information Manager</title>
|
|
<indexterm><primary>information manager</primary><secondary>general information</secondary></indexterm>
|
|
<para>The Information Manager provides on-line access to documentation organized into hierarchies
|
|
of information libraries, bookcases, books, book sections, and smaller divisions of documentation.
|
|
All CDE documentation is shipped with the Information Manager.
|
|
</para>
|
|
<para>To integrate application-specific documentation with the Information Manager,
|
|
a CDE application calls a small API (<Symbol>DtInfo</Symbol>).
|
|
Alternatively, programmers may
|
|
develop their own browsers using the DtInfo Database Engine API (<Symbol>DtMmdb</Symbol>).
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|
|
<!--fickle 1.14 mif-to-docbook 1.7 01/02/96 04:30:53-->
|