Before looking at the program, think of what you would like a drawing editor to offer you. And, if you have any experience in programming graphics applications, how would you approach the implementation of a drawing editor? A drawing editor is a typical example of an interactive program. As a first approximation, we will define a drawing editor that allows the user to paint a series of black dots by pressing and moving the mouse button. See slide ex-hush. }
  #include "hush.h" 
[1]
class drawing_canvas : public canvas {
[2]
public: drawing_canvas( char* path ) : canvas(path) {
(a)
geometry(200,100); handler(this); dragging = 0; } void press( event& ) { dragging = 1; } void motion( event& e) {
(b)
if (dragging) circle(e.x(),e.y(),1,"-fill black"); } void release( event& ) { dragging = 0; } protected: int dragging; }; class application : public session {
[3]
public: application( int argc, char* argv[] ) : session(argc,argv,"draw") {} void main( kit* tk, int, char** ) { canvas* c = new drawing_canvas(".draw"); c->pack(); tk->pack(".quit"); } }; int main (int argc, char* argv[]) {
[4]
session* s = new application(argc,argv); return s->run(); }

slide: A simple drawing tool

The program realizing our first attempt is depicted in slide draw. Again, the program may be broken up in four components. Component [1] consists of simply including the {\tt hush.h} header file. Component [2] defines the class {\em drawing_canvas}. The class {\em drawing_canvas} inherits from the canvas widget class and consequently allows for drawing figures such as a circle. See section canvas and the appendix for further details on the canvas class. Now, before looking at the constructor of the {\em drawing_canvas}, note that the member functions press, motion and release expect a reference to an event. These are precisely the member functions corresponding to the event types for which the canvas is sensitive. The meaning of these member functions becomes clear when looking at the role of the instance variable dragging. When dragging is non-zero and a motion event occurs, a black dot is painted on the canvas. Drawing starts when pressing a mouse button and ends when releasing the button. Turning back to the constructor (a), we see that it expects a path string, which is passed to the canvas ancestor class to create an actual canvas widget. Further, the body of the constructor sets the size of the widget to 200 by 100 and initializes the variable dragging to zero. Finally, the {\em drawing_canvas} widget is declared to be its own handler. The member function handler is defined by the class widget and results in making the widget sensitive to a number of predefined events, that may be different for each concrete widget class. A note on terminology is in place here. The reader may be a bit astounded by the fact that we have both a handler class and a handler function, which is more properly written as widget::handler. The situation may become even more confusing when realizing that the widget class itself is a descendant of the handler class. Schematically, we have the situation as depicted in slide h-disc.
   class widget : public handler {
   public:
   ...
   void handler(class handler* h) { ... }
   ...
   };
  

slide: Handler classes and functions

Note that there is no ambiguity here. A handler object is an object that may be invoked in response to a Tcl command or an event. The handler function declares a handler object to be responsible for dealing with the events that are of interest to the widget. In other words, a {\em drawing_canvas} fulfills the dual role of being a widget and its handler. This must, however, be explicitly indicated by the programmer, which explains the occurrence of the otherwise mysterious expression handler(this). The reason not to identify a widget with a handler is simply that some widgets need separate handlers. Another reason is to avoid the proliferation of the class name space, which would inevitably occur when forcing the programmer to define the response to events by defining a descendant class of the particular widget class. Before studying the abstract handler class in more detail, we will briefly look at the definition of the event class. Note that in (b), the event reference is only used to inform after the position of the mouse pointer.