The core framework classes also include support for features needed by nearly all applications. These classes include VkApp, an application class that must be instantiated by every ViewKit application, classes that support top-level windows, a collection of classes that support menus, and several classes that support dialog management. All classes are designed to fully implement as many typical features as possible. For example, all top-level windows and dialogs handle the window manager quit/close protocol. Dialogs are cached to balance memory use and display speed. The menu system goes beyond simply constructing menus to support dynamically adding, removing, replacing items, and more.
The collection of classes that make up the core part of the ViewKit library are closely integrated and work together to support essential features required by most applications as automatically as possible. Among the basic services supported by the core ViewKit framework are single and multi-level undo, support for performing interruptible tasks, and support for an application-level callback mechanism that allows C++ classes to dynamically register member functions to be invoked by other C++ classes.
Figure 1 shows a typical ViewKit high-level component. This component is a self-contained graph editor/viewer that can be used to browse or create an abstract graph representation consisting of a collection of interconnected objects. Nodes in the graph can be moved interactively. The controls along the bottom of the component allow the graph to be zoomed, the orientation to be changed, and other operations to be performed. An overview of the graph can also be displayed for large graphs. Although the component described here represents a complex sub-system, the entire component can be included in an application simply by instantiating a single C++ class, and using the well-defined interface supported by that class.
Figure 3. A typical high-level ViewKit component.
Creating high-level components such as the graph viewer shown here promotes consistency throughout a set of applications by providing elements that users can learn once and then easily recognize in multiple applications.
One particularly interesting set of utility classes supports operations on groups of widgets. For example, VkRadioGroup allows an arbitrary collection of Motif toggle buttons to exhibit radio behavior, even if these widgets are in different locations in the interface or widget hierarchy. The VkAlignmentGroup class allows developers to specify a collection of widgets that should be aligned to the same width, height, x, or y position.
The ViewKit library supports an easy-to-use collection of classes for building preference panels. Rather than dealing directly with Motif widgets, their placement, callbacks, and so on, programmers who use the ViewKit framework can simply create groups of preference items. These items maintain their own state, which allows an application to simply query each item to see if it has been changed. Layout is handled automatically, and the ViewKit library provides the ability to apply or revert all preferences to their previous state.
The ViewKit library supports integration with the ToolTalk service in two ways. First, the ViewKit framework supplies a higher-level, easy-to-use interface to the ToolTalk library that supports a simple callback model, not unlike the Xt callback mechanism. Second, the ViewKit framework provides various abstract classes that handle many of the details of registering with the message service and handling messages automatically.
The Tooltalk system assumes that messages are handled on an application level (and in fact messages are always sent between processes). However, the ViewKit library also supports individual components that need to encapsulate messaging behavior. For example, imagine a component that allows the user to display and edit some data stored in a file. It is easy to imagine multiple applications using this component to browse or edit the same data simultaneously. Using the ToolTalk communication mechanism, the component can transparently coordinate access and display of the data between applications. For example, if the user edits the data in one view, that view can send notices to other instances of the component to keep them in sync. Because this behavior can be encapsulated in a component, applications that use the component can benefit with no effort on the part of the developer.
Figure 4. Using the ToolTalk mechanism to communicate between processes.
In some situations, audio can be used to emphasize or complement user or system actions. For example, when an error occurs, the framework can post an error dialog and also signal the error audibly. Audio can also be used to subtly enhance the user interface by using audio to smooth transitions and improve the user's perception of the application's response time. In many cases, such features can be provided automatically by the framework. The ViewKit framework also helps by providing consistency in the use of such techniques among multiple applications.
Accepting speech input generally requires some effort on the part of the developer, although a framework can provide support to minimize this effort. A framework can also provide automatic speech input support in some cases. For example, it is reasonable for a framework to allow dialogs to be dismissed verbally, with no effort on the part of the application developer.
___________________________________________________________________
