Visualization

Just as almost any other framework in any domain, CLAM had to think about ways of integrating the core of the framework tools with a graphical user interface that may be used as a front-end of the framework functionalities.

The usual way to work around this issue is to decide on a graphical toolkit or framework and add support to it, offering ways of connecting the framework under development to the widgets and other graphical tools included in the graphical framework. In CLAM though we aimed at offering an toolkit-independent support. This is accomplished through the CLAM Visualization Module.

In order to do so a variant of the Model-View-Controller architectural pattern was implemented. In this new version the main actors are the Presentation, the Model Adapter, and the Model Controller.

A Presentation is a graphical metaphor through which some information contained in the model object is shown to the user. A Presentation can be anything from a simple widget to a full application graphical interface, depending on the complexity of the model object to be presented. A Presentation can be activated and deactivated, therefore its existence does not imply its visibility.

The ModelAdapter class defines the interface that is common to all model object adapters in CLAM Visualization Module. It offers the interface required by the Observable actor in the GOF Observer pattern [Gamma et al., 1995]. The Adapter concept was chosen in order not to taint the model object interface and to separate effectively the model objects from its representation. The main operation in the ModelAdapter class is the abstract Publish operation that must be implemented in all subclasses in order to publish the updated model object internal state.

The ModelController class is similar to the ModelAdapter except in that, besides from publishing the model object state, it also allows to modify it. For that reason it adds the Update operation to the previously mentioned Publish.

The CLAM Visualization Module also implements a Signal&Slots mechanism similar to that offered by frameworks such as QT [Blanchette and Summerfield, 2004]. The basic rationale behind the Signal&Slot mechanism is the following: Sometimes it is required that an object notifies a change in internal state or the reception of a message to any number of listeners. This situation can be modeled in different ways but most of them suffer from a major drawback: coupling. In this sense, the caller must know to some extent the callee interface. Because of this, reuse capabilities are reduced. The Signal&Slot idiom gives solution to this problem. The Signal models the concept of ``event notifying'', and signals are connected to Slots that represent ``event handlers''.

In CLAM the Signal&Slot idiom is implemented through three main classes: the Signal class, the Slot class and the Connection class. The Signal and Slot classes model the obvious concepts previously explained. On the other hand, the Connection class models the knowledge a signal has about who has to be notified whenever a client invokes the Emit() operation on it. Each time a Signal and Slot objects are bound together a Connection object is created, tagged by a Global Unique IDentifierIdentifier (GUID). This particular implementation was loosely derived from [Hickey, 1995].

Apart from the previous tools, the non-dependency from graphical toolkit implementation is also accomplished through the use of a Widget Toolkit Wrapper. This Creator/Singleton class produces objects that are abstract wrappers for accessing a GUI Toolkit low-level functionality such as triggering the event loop, triggering the execution of a single iteration of the event loop or setting the refresh rate for graphic displays.

All this general Visualization infrastructure is completed by some already implemented presentations and widgets. These are offered both for the FLTK toolkit [www-FLTK, ] and the QT framework [Blanchette and Summerfield, 2004,www-QT, ]. An example of such utilities are convenience debugging tools called Plots are also offered. Plots offer ready-to-use independent widgets that include the presentation of the main Processing Data's in the CLAM framework such as audio and spectrum.