The DejaVu framework

introduction framework patterns components conclusions references appendix experience
The problem addressed in the DejaVu project is essentially to provide support for the software engineering of (moderately complex) applications that require, apart from other functionality, multimedia interfaces and associative online help. Such support is primarily offered in the form of class libraries, most of which are written in C++. The language C++ was chosen for pragmatic reasons, since it allows for easily wrapping public domain software written in C in classes with a more user-friendly interface. Another reason was that C++ seemed to be the right vehicle for programming assignments, with regard to its ever more widespread use.

Application development generally encompasses a variety of programming tasks, including system-level software development (for example for networking or multimedia functionality), programming the user interface (including the definition of screen layout and the responsivity of the interface widgets to user actions), and the definition of (high-level) application-specific functionality. Each of these kinds of tasks may require a different approach and possibly a different application programming language. For example, the development of the user interface is often more conveniently done using a scripting language, to avoid the waiting times involved in compiling and linking. Similarly, defining knowledge-level application-specific functionality may benefit from the use of a declarative or logic programming language  [VE95].

In our project, we decided from the start to support a multiparadigm approach to software development and consequently we had to define the mutual interaction between the various language paradigms, as for example the interaction between C++ and a scripting language, such as Tcl  [Tcl]. Current scripting languages, including Python  [Python] and Tcl, provide facilities for being embedded in C and C++, but extending these languages with functionality defined in C or C++ and employing the language from within C/C++ is rather cumbersome. The hush library offers a uniform interface to a number of script languages, and in addition, it offers a variety of widgets and multimedia extensions, that are accessible through any of the script interpreters as well as the C++ interface.

Basic concepts

These concepts are embodied in (pseudo) abstract classes that are realized by employing patterns based on idioms extending the handle/body idiom, as explained later on. Programming a hush application requires the definition of an application class derived from session to initialize the application and start the (window environment) main loop. In addition, one may bind (C++) handler objects to script commands by invoking the kit::bind function. Handler objects are to be considered an object realization of callback functions, with the advantage that client data may be accessed in a type-secure way (that is either by resources stored when creating the handler object or by information that is passed via events). When invoked, a handler object receives a pointer to an event (that is, either an X event or an event related to the evaluation of a script command). The information that results from binding a handler to a script command is stored in an action object, that is used by both widgets and (graphical) items to bind window events (resulting from user actions) to the handler (callback) objects. Both the widget and item class are derived from handler to allow for declaring widgets and items to be their own handler.

The art of hush programming

In fact, every class in the hush library (except for the handler class itself) is derived from the handler class, to allow for defining a script interface for these classes. In a similar way, the extensions to hush are required to define appropriate widget classes, and possibly specialized handler classes and event classes dealing with particular events (such as for example file descriptor events for communicating via sockets or notification events resulting from joining a ToolTalk session  [ToolTalk]). The extensions include For the average user, programming in hush amounts (in general) to instantiating widgets and appropriate handler classes, or derived widget classes that define their own handler. However, advanced users and system-level programmers developing extensions are required to comply with the constraints resulting the patterns underlying the design of hush and the application of their associated idioms in the realization of the library. In the next section, we will outline the rules of the game.
introduction framework patterns components conclusions references appendix experience