Using the ToolTalk Desktop Services Message Set

The ToolTalk Desktop Services Message Set allows an application to integrate
and control other applications without user intervention. This section presents
two scenarios ("The Smart Desktop" and "Integrated Toolsets")
that show how the Desktop Services Message Set might be implemented.

The Smart Desktop

Note -

The scenario in this section is intended to illustrate how the
ToolTalk service can be used in an application-level program that interprets
user requests; it is not intended to illustrate how
the Common Desktop Environment product implements the ToolTalk service to
interpret user requests.

A common user requirement for a graphic user interface (GUI)
front-end is the ability to have data files be aware (or "know")
of their applications. To do this, an application-level program is needed
to interpret the user's requests. Examples of application-level programs
(known as smart desktops) are the Apple Macintosh finder,
Microsoft Windows File Manager, and the Common Desktop Environment File
Manager. The key common requirements for smart desktops are:

Takes a file

Determines its application

Invokes the application

The ToolTalk Service provides additional flexibility by allowing classes
of tools to edit a specific data type. The following scenario illustrates
how the Desktop Services Message Set might be implemented as a smart desktop
transparent to the end-user.

Diane double-clicks on the File Manager icon.

The File Manager opens and displays the files in Diane's current
directory.

Diane double-clicks on an icon for a data file.

a.

The File Manager requests that
the file represented by the icon be displayed. The File Manager encodes the
file type in the display message.

b.

The ToolTalk session manager
matches the pattern in the display message to a registered
application (in this case, the Icon Editor), and finds an instance of the
application running on Diane's desktop.

Note -

If the ToolTalk session manager does not find a running instance
of the application, it checks the statically-defined process types (ptypes)
and starts an application that best matches the pattern in the message. If
none of the ptypes matches, the session manager returns failure to the File
Manager application.

c.

The Icon Editor accepts the display message, de-iconifies itself, and raises itself to the
top of the display.

Diane manually edits the file.

Integrated Toolsets

Another significant application for which the Desktop Services Message
Set can be implemented is integrated toolsets. These
environments can be applied in vertical applications (such as a CASE developer
toolset) or in horizontal environments (such as compound documents). Common
to both of these applications is the premise that the overall solution is
built from specialized applications designed to perform one particular task
well. Examples of integrated toolset applications are text editors, drawing
packages, video or audio display tools, compiler front-ends, and debuggers.
The integrated toolset environment requires applications to interact by
calling on each other to handle user requests. For example, to display video,
an editor calls a video display program; or to check a block of completed
code, an editor calls a compiler.

The following scenario shows how the Desktop Services Message Set might
be implemented as an integrated toolset:

Bruce is working on a compound document using his favorite editor.

He decides to change the some of the source code text.

Bruce double-clicks on the source code text.

a.

The Document Editor first determines
the text represents source code and then determines which file contains the
source code.

b.

The Document Editor sends an edit message request, using the file name as a parameter for the
message.

c.

The ToolTalk session manager
matches the pattern in the edit message to a registered
application (in this case, the Source Code Editor), and finds an instance
of the application running on Bruce's desktop.

Note -

If the ToolTalk session manager does not find a running instance
of the application, it checks the statically-defined ptypes and starts an
application that best matches the pattern in the message. If none of the
ptypes matches, the session manager returns failure to the Document Editor
application.

d.

The Source Code Editor accepts
the edit message request.

e.

The Source Code Editor determines
that the source code file is under configuration control, and sends a message
to check out the file.

f.

The Source Code Control application
accepts the message and creates a read-write copy of the requested file. It
then passes the name of the file back to the Source Code Editor.