Common Desktop Environment: Programmer's Overview

ToolTalk Messaging Service

The Common Desktop Environment defines two standard ToolTalk protocols known as message sets. A message set contains a number of messages that can be exchanged between a sender and a handler process. These message are grouped together because they describe related requests and notices. The sender and recipient can be within the same process or on different hosts. Message sets have associated utility functions that enable you to concentrate on the semantics of the protocol without getting too involved in low-level details. Some message set functions enable you to easily defer to default behavior.

The desktop message set encompasses three areas:

Windowing behavior
File access and short-term file lifecycle control
Application extension languages

See "Handle Desktop" and "Send Desktop" for information on windowing behavior. See "Desktop File" for information on file access and short-term file lifecycle control. Implementing the Do_Command request is specific to the application's extension language and is not assisted by the ToolTalk Messaging Service.

The media message set enables an application to be a container for arbitrary media or to be a media player and editor that can be driven from such a container. The media message set enables a container application to compose, display, edit, and print a document of an arbitrary media type, without understanding anything about the format of that media type. The ToolTalk Messaging Service 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. See "Send Media" and "Handle Media".

Message Sets

The ToolTalk Messaging Service provides support for these message sets:

Handle Desktop

Handling desktop requests is the most basic level of messaging integration. Any application that sends ToolTalk messages, either through calling tt_message_send() or DtActionInvoke(), should handle the desktop requests. This enables other applications to set or query things such as your application's current directory, iconic state, and $DISPLAY. For further information, see the man pages for ttdt_open(), ttdt_session_join(), ttdt_session_quit(), and ttdt_close().

Send Desktop

When an application is started by ttsession to handle some ToolTalk request, it is a child of ttsession rather than of the request sender. The application will usually be started on the same X display session as the sender, but not necessarily on the same X11 screen or in the same current directory context. If the application is implemented as a server process, it may already be displaying on a particular screen or in a particular directory context.

Using desktop requests, a handling application can inherit from the sender attributes that might otherwise be inherited through command-line invocation. Use the desktop message set in this way to reset the handler's locale, current working directory, and even $DISPLAY. This enables a carefully coded receiving application to come up on the same X11 screen as the sender. A request handler can also find out the request sender's current directory and window geometry. Knowing the window geometry enables the request handler's window to avoid obscuring the request sender's window, if possible. For more information, see the ttdt_sender_imprint_on() man page.

Handle Media

The ToolTalk Messaging Service enables an editor to easily handle the standard media requests for the media types for which the editor is responsible. For further information, see the man pages for ttmedia_ptype_declare(), ttdt_message_accept(), ttmedia_load_reply(), and ttmedia_Deposit().

Send Media

The ToolTalk Messaging Service enables a container to easily send media requests and manage the subsequent document updates sent back by the handler. In those cases in which the container doesn't engage in any ongoing ToolTalk dialog with a media handler, use the actions API instead of directly using these ToolTalk APIs. Equivalent actions (Open and Print) represent a higher level of abstraction that supports the equivalent of ToolTalk and non-ToolTalk aware media handlers. For further information, see the man pages for ttmedia_load() and ttdt_subcontract_manage(). Note that, in most cases, a container application should perform operations on objects using DtActionInvoke() instead of ttmedia_load(). See the Common Desktop Environment: ToolTalk Messaging Overview for a description of how ToolTalk applications can be driven using actions.

Desktop File

The ToolTalk Messaging Service makes it easy to send and receive the desktop messages about files. These messages enable applications to coordinate access to files. For further information, see the man pages for ttdt_file_join(), ttdt_file_quit(), ttdt_file_event(), ttdt_Get_Modified(), ttdt_Save(), and ttdt_Revert().

Examples of applications that already use the ToolTalk Messaging Service include the Common Desktop Environment Icon Editor, Mailer, Text Editor, and Calendar. Other parts of the Common Desktop Environment use the ToolTalk Messaging Service indirectly by defining actions that send messages.

Library and Header Files

The ToolTalk messaging library is called libtt. The libtt header files are:

Tt/tt_c.h
Tt/tttk.h

Demo Programs

You can find the ToolTalk Messaging Service demos in /usr/dt/examples/tt. Read the README file for detailed information on the demos.