Components

• hush
• widgets
• hypertext
• sms
• music
• video
• web

The hush API

The hush library contains the classes kit, event, handler, widget and item. In addition to these, hush provides the class session. Application programmers are minimally required to derive a class, say application, from session and redefine the function main. When the program is to be used as a script interpreter, the function prelude may be redefined to allow for initializing external packages or other components of the DejaVu framework.

As a comment, the hush library originated as a collection of classes giving the C++ programmer convenient access to the Tcl/Tk window programming toolkit. Its design has been inspired by the Interviews library. However, although less powerful wit respect to device-independent graphics, its class structure is less complex and, as experience shows, much easier to employ by undergraduate students. In addition, it offers a rich collection of user interface widgets.

User interface widgets

  button* b = new button(".b");
  handler* h = new help_handler(b);
  b->text("Help");
  b->bind(h);

Alternatively, a widget may declare itself to be its own handler. In that case we derive a new class from button and define the functionality (previously defined externally in the help_handler) in the new class itself, as illustrated below:

  class help_button : public button {
  public:
  help_button( char* path ) : button( path ) {
	this->text("help");
	this->bind(this);
	}
  int operator()(); // does what help_handler did
  };

Basic hypertext functionality

Software sound facilities

The DejaVu framework supports both MIDI and the sound synthesis facilities offered by Csound [XX]. When creating an instance of the icsound class a process is created which is capable of receiving sound events, as defined by the Csound numerical score language, and converting these events to data for the audio device. (The icsound class inherits from a wrapper class providing the functionality for spawning of a new process that communicates with the original process via pipes.) Care is taken that the audio device is connected only once. However, multiple instances of the icsound class may exist.

In addition to the icsound class, which accepts only low level sound events, instances of player may be used which accept musical events defined in the high level music description language Scot, that comes with Csound. The player class is also an event. This allows instances of player to be embedded in scripts, as well as being activated as user-defined events.

Digital video

Our video extension is based on the public domain xanim package and includes support for MPEG, AVI and Quicktime.

Connecting to the WWW

 <h1>Digital video for HushWWW</h1>
 <hush tcl=source [urlfile www.cs.vu.nl/~se/mpeg.tcl>;
 You need the hush browser to play this MPEG demo 
 </hush>

Example -- simulation on the Web

Embedding simulations

---

A simulation embedded in two HTML pages

---

Figure Dining shows the corresponding HTML markup for the first page. We use two <app> tags to include inline applets written in Tcl/Tk. Note that text inside the open and close tag will be ignored by our browser and may be used to display warnings if the page is browsed by non-hush browsers as Mosaic or Netscape.

  <title>The Dining Philosophers<title>
  <h1>The Dining Philosophers<h1>
  <h2>The problem<h2>
    Five philosophers sit around a table, with five chopsticks in between.
    ...
    We are interested in <a href="results.html">the percentage of the time<a> a 
    philosopher actually thinks. 
  <app class="sim-setup">
    Error: Dining table deleted: use our hush browser!
  </app> <hr>
  Press this button: <app class="sim-button">
    Error: Run button deleted: use our hush browser!
  </app>

The Tcl/Tk applets used in the example above are in fact only responsible for the graphical interface, the simulation itself is modeled in C++, by refining the entity class (modeling a philosopher) and the resource class (modeling a chopstick) of the simulation library.

The simulation is initialized by scheduling five philosopher entity objects in a "waiting" phase at time t=0.0. The "simulation init" command will be executed by first applet. The simulation can be started by executing the "simulation run" command, which is bound on a push button by the sim-button applet.

When a philosopher is due to be activated, the scheduler will call its application operator which will perform an explicit dispatch on the current phase:

  int philosopher::operator()() {
      switch (phase()){
        case EATING   : eat();   return OK;
        case THINKING : think(); return OK;
        case WAITING  : await(); return OK;
        default: return FALSE; // undefined phase
      } 
  }

Suppose the philosopher is still in a waiting phase. The await() member will be called and the philosopher will see whether his chopsticks are available. If so, she will acquire them and starts eating. If not, the philosopher will remain in a waiting state, but is put on the scheduler's list of conditional events.

  void philosopher::await() {
    if (chopsticks_available()) {
        acquirechopsticks();
  
        phase(EATING);
  
    } else if (!conditional()) {
        waitonchopsticks();
        sim->hold(this);
    }
  }

However, if the philosopher is invoked while she is in a eating phase, she will continue with eating for some (exponentially distributed) random time interval after which she will move to a "thinking" phase.

  void philosopher::eat() {
    double t = gen->exponential(EAT_TIME);
    phase(THINKING);
    sim->wait(t);
  }

Multimedia Scheduling

In addition, we extended the simulation package with a soft-real time option, that allows us to schedule clock-synchronized events. For example, we implemented a simple slide show, by the repetitive scheduling of HTML pages with a fixed time interval.

However, general hypermedia applications require support for far more complex synchronization relations and temporal dependencies between the components of a hypermedia document. Such high-level temporal alignment cannot be (easily) expressed using the basic simulation primitives, nor can the corresponding documents be expressed by (text oriented) markup languages as HTML.

Therefor, we are currently developing components supporting more complex scheduling primitives. One of our goals is to add a (subset of) the event scheduling mechanisms of HyTime [REFXXX] to our new, SGML-based Web widget.

Implementation and design -- patterns

Choosing an interpreter

To illustrate our approach, look at the definition of the class kit:

  class kit {
  public:
    kit( char* kind = "tcl" );

    virtual int eval(char* cmd) { return _kit?_kit->eval(cmd):0; }
    ...
  protected:
    kit( kit* );
    kit* _kit;
  };

  class tcl_kit : public kit {
  public:
    tcl_kit() : kit(0) { ... }
    ...
  };

Multiple perspectives on events

  class event : public handler {
  public:

    event( event* x ); // expects x event
    event( );          // creates sim event

    // X event interface

    virtual int type() { return _event?_event->type():0; }

    virtual int x() { return _event?_event->x():0; }
    virtual int y() { return _event?_event->y():0; }

    // simulation interface

    virtual void timestamp();
    virtual double timespent() { return _event?_event->timespent():0; }

  protected:
    event* -event;
  };

The (public) constructor event::event(event*) is used to encapsulate events generated by the (X) window system. An advantage of this approach is instance may be accessed via both pointer and object references, without sacrificing dynamic binding. (To our taste, it is more natural to write e.x() than e->x() when accessing the x coordinate of the mouse pointer stored in an event instance.)

For events that are to be scheduled under programmer's control, a class must be specified inheriting from event (overriding the operator() activation function). In that case a simulation event is created containing the additional data structures needed for bookkeeping and scheduling.

Virtual self-reference

  class drawtool : public canvas {
  public:
    drawtool() : canvas() { }     // to declare drawtool
    drawtool(char* path) : canvas() {
	initialize( path );             // constructs the components
	redirect( _canvas );      // delegate to _canvas component
	}
    int operator()() {              // interface to Tcl
	if ( !strcmp("drawtool",argv[1]) return create(argc, argv);
	else return self()->eval( flatten(argc, argv) );
	}
  private:
    void initialize( char* path ); 
    int create( int argc, char* argv[] );
    canvas* _canvas;
  };

  tk->action("drawtool", new drawtool() );

The call redirect(_canvas) in the regular constructor results in delegating both member function calls and script commands addressed at the drawtool widget to the canvas widget pointed to by _canvas, which is assumed to be created in initialize. The _canvas widget acts, so to speak, as the primary component of drawtool in that it receives all bindings and (configuration) commands. Actual redirection occurs by calling self(). The definition of widget::self() is simply:

  widget* self() { return _self?_self->self():this; }

Those well-versed in design patterns will recognize the Decorator patterns (as applied in the Interviews MonoGlyph class  [Interviews89]).

Practice and experience

Platform/compiler dependencies

    class handler { ... }
  
    class widget : public handler {
    public:
      ...
      void handler( class handler* h );  // to install a default handler
      ...
    };
  

Much time was spent in finding ways to satisfy both the GNU compiler and the AT&T compiler (and later the Sun CC 4.0 compiler). A situation which is unfortunately still characteristic for working with C++. Much time was also spent in adapting to differences in include files and linking conventions when moving to Solaris. We deal with different platform and compilers now by providing configuration set up files, trying to avoid as much as possible to clutter our code with conditional compilation macro instructions.

Configuration management

• api -- for hush and the widget libraries,
• packages -- providing hymne, sim and the web library,
• media -- for xanim and the vrml extensions,
• support -- for a variety of other libraries,
• tcltk -- for the Tcl/Tk libraries,
• contrib -- which contains the Tcl/Tk extensions, and
• tools -- which contains a number of documentation tools.

Documentation support

Conclusions

Another question that may arise is how the notions of handlers and events are related to a hypermedia document model. The answer must be, only in a very loose fashion, that is to the extent that we need (and support) embeddable anchors and (in the future) a linkbase facility to store and retrieve associative links.

For developing actual hypermedia systems we need to provide support in the form of actual widgets (including a hypertext widget) and, equally important, guidelines and patterns for developing applications. In addition, we have to provide adequate documentation support.