13.5.2. Writing Tk Applications

Even the basic Tcl knowledge given in the previous section is enough to allow you to write applications using Tk, the Tcl extensions for the X Window System. Tk is essentially a collection of Tcl commands that create and manipulate X widgets--such as buttons, scrollbars, menus, and so forth. As we will see, Tk is extremely versatile and greatly simplifies the task of building a graphical user interface under X.

A widget is an object you want to manipulate, such as a rectangle. Each widget requires memory and a bunch of properties, but Tk relieves you from thinking about all that. You just create a widget and tell Tk what you want it to look like.

Figure 13-2. Window displayed by Tk program

Let's walk through the source for our application, draw.tcl:

#!/usr/bin/wish -f
# Global variables, used to keep track of objects and positions
set oval_count 0
set rect_count 0
set orig_x 0 
set orig_y 0

No sweat here: we simply initialize a few variables to keep track of the oval and rectangle objects we create, as well as the location of the object as it is created.

The next portion of the source may be a bit daunting at first:

# This procedure enables ovals.
proc set_oval {} {
  # Allow us to access these global variables
  global oval_count orig_x orig_y

  # When button-1 is pressed, create an oval
  bind .c <ButtonPress-1> { 
    set orig_x %x
    set orig_y %y
    set oval_count [expr $oval_count + 1]
    .c create oval %x %y %x %y -tags "oval$oval_count" -fill red 
   }

  # When we drag button 1, delete the current oval and replace it
  bind .c <B1-Motion> { 
    .c delete "oval$oval_count"
    .c create oval $orig_x $orig_y %x %y -tags "oval$oval_count" -fill red
  }
}

Here, we define a procedure named set_oval using the Tcl proc command. The first argument to proc is the list of arguments that the procedure will take; in this case, there are none. The second argument is the body of the procedure itself. This procedure is invoked when we select the Ovals item from the Objects menu, which is configured later in this section.

The first thing set_oval does is declare the variables oval_count, orig_x, and orig_y to be globals; otherwise, Tcl would assume we were using these variables locally within the procedure.

The next task is to bind an action to a ButtonPress event in the canvas widget we will be drawing into. This widget is named .c. Tk widgets are named hierarchically. The widget . (a period) refers to the main application window. Any widgets created within that window are given names beginning with a period, such as .c (for a canvas widget), .mbar (for a menu bar), and so on. Of course, the programmer can choose widget names, but those names must begin with a period. As we will see later, widgets may be contained within other widgets; for example, a menu is contained within a menu bar. A widget named:

.mbar.file.menu

In this case, we wish to start drawing an oval whenever the user presses mouse button 1 in the canvas widget. The code of the binding sets the variables orig_x and orig_y to %x and %y, respectively. Within a binding, %x and %y refer to the x and y coordinates of the event in question. In this case, this would be the cursor position where the mouse button was pressed. We wish to save this location when the oval is resized. In addition, we increment the oval_count variable.

The ButtonPress-1 binding also executes the command:

.c create oval %x %y %x %y -tags "oval$oval_count" -fill red

The -tags option to the canvas create command assigns a "name" to the newly created oval object. In this way, we can refer to this particular oval on the canvas widget by its name. To ensure that each oval has a unique name, we use the oval_count variable, which is incremented each time an oval is created.

When the mouse is dragged with button 1 pressed, we wish to resize the oval. This is accomplished by setting a binding for the B1-Motion event in the canvas widget. This binding executes the two commands:

.c delete "oval$oval_count" 
.c create oval $orig_x $orig_y %x %y -tags "oval$oval_count" -fill red

We define an analogous set_rect function, which is nearly identical to the one previously discussed, but creates canvas rectangle objects instead:

# Identical to set_oval, but uses rectangles
proc set_rect {} {
  global rect_count orig_x orig_y
  bind .c <ButtonPress-1> { 
    set orig_x %x
    set orig_y %y
    set rect_count [expr $rect_count + 1]
    .c create rectangle %x %y %x %y -tags "rect$rect_count" -fill blue
  }
  bind .c <B1-Motion> { 
    .c delete "rect$rect_count"
    .c create rectangle $orig_x $orig_y %x %y -tags "rect$rect_count" \
      -fill blue
  }
}

Another way to draw rectangles and ovals would be to have a generic "draw object" function that uses a variable, say $objtype, to keep track of the current object type. The menu settings (described later) select the object type by setting the value of this variable. In the drawing function, we could simply use a canvas command such as:

.c create $objtype %x %y %x %y -tags "obj$obj_count" -fill blue

Now we are ready to define the various widgets that make up our application. First, we need to create a frame widget to be used as a menu bar. A frame widget merely acts as a container for other widgets:

# Create a frame widget to be used as a menubar.
frame .mbar -relief groove -bd 3
pack .mbar -side top -expand yes -fill x

The pack command places widgets within the application window, or within other widgets. It is one kind of "geometry manager" available for Tk. In order for a widget to be displayed within the application, a geometry manager must be called to place the widget. pack is provided with Tcl/Tk, and is versatile enough for almost any application. pack allows you to specify how widgets should be placed relative to one another, without having to specify absolute locations.

In this case, we pack the .mbar widget into the top edge of its parent widget, which is . (the main application window). The -fill x option tells pack that the widget should be allocated the entire width of the window in which it is contained; the -expand option specifies that the widget should grow to fill that space. If you are interested in the intricacies of pack, the Tk pack manual page provides a great deal of detail.

Next, we create two menubutton widgets within this menu bar--the File and Object menus:

# Create two menu items
menubutton .mbar.file -text "File" -menu .mbar.file.menu
menubutton .mbar.obj -text "Object" -menu .mbar.obj.menu
pack .mbar.file .mbar.obj -side left

The -menu option to the menubutton command specifies the menu widget that should be displayed when this pulldown menu is selected. We will create the .mbar.file.menu and .mbar.obj.menu widgets later:

# Create the file menu, and add a single "Quit" item to it
menu .mbar.file.menu
.mbar.file.menu add command -label "Quit" -command { exit }

# Create the object menu, and add two radiobutton objects to it
menu .mbar.obj.menu
.mbar.obj.menu add radiobutton -label "Ovals" -variable objtype \
  -command { set_oval }
.mbar.obj.menu add radiobutton -label "Rectangles" -variable objtype \
  -command { set_rect }

Here, we create the Objects menu, and add two objects of type radiobutton to it. Radiobuttons define a set of options where only one of the options may be selected at a given time. For example, when Ovals is selected, it is highlighted in the menu and Rectangles is dimmed.

In order to "link" the two radiobuttons (so that only one may be selected at a time), we use the -variable option to specify a "dummy" variable that keeps track of the current setting of the radio buttons. The -variable option may be used in conjunction with -value, which assigns a value to the named variable when the menu item is selected. Instead, we choose to execute a procedure (specified with the -command option) when the menu item is selected, which precludes the need for -value.

Next, we create our canvas widget and pack it into the application window:

# Create the canvas .c
canvas .c
pack .c -side top

Finally, we enable the Ovals option by artificially invoking the corresponding menu item. This is exactly what happens when the user selects the menu item using the mouse:

# Turn on ovals, by invoking the first item in the object menu
.mbar.obj.menu invoke 0

Here, in a few dozen lines of code, we have a complete, relatively complex X application. There are many easy ways to extend this program: for example, by adding new object types, allowing the user to save and load "pictures" created with it, and so on. In fact, the canvas widget even supports an option to dump a PostScript image of its contents, which then can be printed.

13.5.3. Using Tcl and Tk in Other Applications

As mentioned previously, you can use Tcl and Tk with other programs written in languages such as C or Perl. Writing a complex program as a Tcl/Tk script is possible, but it would probably be slower than coding it in a compiled language because Tcl is interpreted. Although Perl is interpreted as well, Perl is suited to many tasks that are more difficult to accomplish in Tcl or C.

The canonical way to use Tcl and Tk with a C program is to link the Tcl and Tk libraries with the C code. Tcl and Tk provide simple .a static libraries, as well as shared .so libraries on some systems. The Tcl interpreter is implemented as a series of functions that your program calls.

The idea is that you implement new Tcl commands as C functions, and the Tcl interpreter calls those functions when one of those commands is used. To do this you must structure your program to initialize the Tcl interpreter and use a Tcl "main loop," which reads Tcl commands from some location (such as a file) and executes them. This is roughly equivalent to building your own tclsh or wish interpreter with a few extra Tcl/Tk commands implemented in C.

This may not be the best solution for all applications. First of all, it requires some of your program to be restructured, and the Tcl interpreter ends up controlling the application--not the other way around. Also, unless you use shared Tcl and Tk libraries, having a complete Tcl/Tk interpreter embedded in your application can make the binary quite large--well over a megabyte. Also, your application may depend on some kind of Tcl script to drive it, which means that the executable is not enough to use the complete application: you need the driving script as well.

The most straightforward way of setting this up is to write a C function that does the following (in pseudocode):

Create two pipes by calling pipe() twice;
Use fork() to start a child process;
  In the child process, 
    close the read end of one pipe and the write end of another;
    Use dup2() to duplicate stdin and stdout to the appropriate pipes;
    Use execlp() to start wish;
  In the parent process;
    close the read end of the write pipe, and the write end of the
      read pipe;
    Use fdopen() on each pipe to get a FILE descriptor for use with
      fprintf() and fscanf();

The parent process (your C application) can now write Tcl/Tk commands to the write pipe and read responses from wish on the read pipe. The select function can be used to poll for data on the read pipe, in case you want your application to keep processing while waiting for data from the wish interpreter.

This way, we treat wish as a "server" for X Window System routines. Your program would send widget-creation commands down the write pipe. wish could be told to print a string to standard output when a response is required from the application. For example, a button widget could be created that prints the string okay button pressed when pressed by the user. Your program would read this string on the read pipe and respond to it. Other parts of the application could be controlled by wish without your application's knowledge. The computing-intensive, speed-critical parts of the application would be coded in C, and the interface handled by wish.

Hopefully, the overview here should be enough to give you an idea of how to write a C or Perl program that uses wish in this way. It's a good idea to read a book on Unix systems programming that talks about interprocess communication using pipes, such as Advanced Programming in the UNIX Environment by Richard Stevens or UNIX System Programming by David Curry.