Go backward to 3 A Distributed Mathematica Environment Go up to Top Go forward to 5 Session Operation

4 Notebook Control

Our original motivation stems from the desire to have the notebook frontend of the lecturer control all the notebook frontends of her audience. For this purpose, two requirements must be fulfilled:

1. The interaction of the lecturer with her frontend must trigger corresponding messages to the kernel (such that these messages can be intercepted).
2. It must be possible to trigger state changes of a notebook in a frontend by external sources (e.g. by messages from the kernel).

Unfortunately, the standard Mathematica frontend fulfills the first demand only to a small extent:

• First, all user interface events (like scrolling the notebook in a window) are directly handled by the frontend.
• However, also basic notebook manipulation takes place in the frontend; e.g. reading a notebook from a file, opening/closing a notebook cell, selecting and updating the content of a cell, and navigating from one cell to another.
• Only the evaluation of active notebook contents (triggered by pressing the Shift-Return key) creates an EvaluatePacket sent to the kernel which responds to the frontend by a corresponding ReturnPacket.

After so many bad news, it is relieving to see that at least the second demand is essentially met:

• Each notebook open in the frontend may be represented by a a NotebookObject in the kernel.
• The kernel may trigger the transfer of the current notebook state from frontend to kernel (command NotebookGet) and vice versa (NotebookPut). It may also determine the current selection in a notebook in the frontend (NotebookSelection).
• Most important, each frontend operation on a notebook may be performed by a corresponding kernel operation.

Consequently, each user event that triggers a change in the state of a notebook can be in principle mirrored by a corresponding operation in the kernel which updates the notebook in the frontend. More specifically:

• A notebook cell may be opened or closed (command SetOptions).
• Selected contents may be retrieved (NotebookRead) and updated (NotebookWrite).
• The current notebook selection in the frontend may be moved from one cell to another (SelectionMove, NotebookLocate).
• The kernel may trigger the execution of some frontend operations (FrontEndExecute).

Of course, this still leaves the problem how to determine the control operations performed by the lecturer, for the frontend does not propagate this information to the outside. Since it is out of question to write a complete notebook frontend from scratch, we see three possibilities:

Embedded Control.

We may embed control into a notebook itself by adding control buttons to the notebook. Such control buttons are a special form of active notebook contents: when pressed, execution of a user-defined command is triggered in the kernel. By attaching a SelectionMove command to such a button, it may serve the same purpose as a link in hypertext documents.

The advantage of this solution is its technical simplicity, but it requires the corresponding modification of notebooks for distributed presentation.

Control Palette.

Instead of hardwiring navigation into the document, corresponding facilities may be added to the frontend by providing a control palette. A palette is a menu of buttons that can be defined by the user and that is displayed by a separate window in the frontend (see Figure 2). When one of the buttons is pressed, a user-defined command is executed in the kernel. In contrast to the "embedded control" solution, however, this command cannot carry any context information; the kernel itself therefore has to remember the current notebook state and update the notebook accordingly.

This solution does not require modifications in the notebook; instead a Mathematica program running in the kernel must remember and update notebook states accordingly. Still only simple control events without additional arguments can be handled in this way.

Remote Control.

The interceptor process may be extended by a "remote control" with a corresponding interface that the lecturer uses for notebook control. This remote control generates messages that are transmitted to the kernel which subsequently triggers the corresponding updates in the frontend.

This solution shifts the functionality of the control palette from the frontend to the interceptor process. By an appropriate user interface, arbitrary user input may be incorporated into messages to the kernel. Moreover, the control interface itself can encapsulate part of the notebook state (e.g. the current position) and forward this information to the kernel (thus relieving the kernel program from this task).

The ultimate solution will probably consist of a combination of these possibilities; their appropriate mixture and area of application will be subject of investigation. In any case, some care has to be taken to prevent the individual session participants from modifying their notebook duplicates during the lecturer's presentation. For this purpose, the interceptor process may reset the state flag Editable when it receives a new notebook. On the other hand, the lecturer should not be allowed to perform operations via the standard frontend that are not appropriately propagated to the audience. There is no apparent technical solution to overcome this problem; as a pragmatic remedy we may display on the lecturer's host in a separate window the audience's view of the notebook such that the lecturer may detect inappropriate actions early.