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.