Integrating Multimedia Functionality

Integrating multimedia functionality into an application allows end-users of the application to embed various media types in their documents.

Typically, an icon that represents the media object is embedded in the document. Upon selection of an embedded object, the ToolTalk service automatically invokes an appropriate external media application and the object is played as illustrated in the following scenario.

1. Daniel opens a document that contains multimedia objects.

2. The window shows the document with several icons representing various media types (such as sound, video, and graphics).

3. Daniel double-clicks on the sound icon.

   A sound application (called a player) is launched and the embedded recording is played.

4. To edit the recording, Daniel clicks once on the icon to select it and uses the third mouse button to bring up an Edit menu.

   An editing application is launched and Daniel edits the media object.

Adding Multimedia Extensions to Existing Applications

The ToolTalk Document and Media Exchange Message Set also allows an application to use other multimedia applications to extend its features or capabilities. For example, a calendar manager can be extended to use the audiotool to play a sound file as a reminder of an appointment, as illustrated in the following scenario:

1. Karin opens her calendar manager and sets an appointment.

2. Karin clicks on an audio response button, which causes the soundtool to pop up.

3. Karin records her message; for example, "Bring the report."

When Karin's appointment reminder is executed, the calendar manager will start the audiotool and play Karin's recorded reminder.

Extending the X Cut and Paste Facility

The ToolTalk Document and Media Exchange Message Set can support an extensible, open-ended translation facility. The following scenario illustrates how an extensible multimedia cut and paste facility could work:

1. Maria opens two documents that are different media types.

2. Maria selects a portion of Document A and cuts the portion using the standard X-windowing cut facility.

3. Maria then pastes the cut portion into Document B.

   1. Document B negotiates the transfer of the cut data with Document A.

   2. If Document B does not understand any of the types offered by Document B, it requests a tagged media type. Document B uses the tagged media type to broadcast a ToolTalk message requesting a translation of the media type to a media type it understands.

   3. A registered translation utility accepts the request and returns the translated version of the media type to Document B.

   4. The paste of the translated data into Document B is performed.

Using the CASE Interoperability Message Sets

The CASE Interoperability Message Sets allow an application to integrate and control other applications without user intervention. This section illustrates several scenarios that show how the CASE Interoperability Message Sets might be used.

User Scenario: Fixing Bugs

This scenario steps through a complete cycle of how to fix a bug for a released application. It begins with receiving the bug report and describes the process required to fix the problem.

1. Larry receives a bug report that indicates his application has a problem.

2. Larry invokes his CASE environment.

   A CASE user interface is displayed. The functions Larry wants to perform are available in this CASE user interface.

3. Larry writes a test case that duplicates the failure stated in the bug report.

4. Larry selects the debug function to run the application against the test case.

   1. A Debug request is sent.

   2. The messaging environment selects the debugging application. It does not find an instance of the application running in Larry's CASE environment, so it automatically starts a debugger.

   3. The debugging application receives the request and loads the binary.

5. Larry tests the code and reviews the debugging state in the debugging window.

   He finds a function call that appears to be passing incorrect arguments.

6. Larry selects the edit function to edit this code.

   1. The debugging tool sends an edit request.

   2. The source editor receives a message to edit the specified source file.

7. Larry wants to modify the source code, so he selects the checkout function.

   1. The source code editor sends a checkout request.

   2. The source code editor receives the checkout notification, and changes the buffer state to modifiable.

8. Larry edits the source code to fix the bug and selects the Build function to build the application.

   1. The build request is sent.

   2. The build application receives the build request, and performs the build.

   3. When the build completes, the build application sends the BuildFinished notice.

   4. The debugger receives the BuildFinished notice and reloads the newly built application binary.

9. Larry retests the application to confirm the bug fix works.

10. Larry exits the CASE environment.

    1. Quit requests are sent to the source code editor, debugger, version manager, and builder applications.