next up previous contents index
Next: Communication Up: LTK - a Lisp Previous: Window manager functions   Contents   Index

Under the hood

In this section, the technical detaills of the implementation and workings of ltk are explained. Reading this section should not be neccessary to use ltk, but helps understanding it and serves as a documentation for those, who want to extend ltk.

The Tk library is a GUI library for the tcl programming language. It is used via the program wish. Commonly, it is used as the shell to execute tcl/tk programs. But when no script name to execute is being given, it starts in an interactive mode, using stdin to read commands and stdout to print the results. This can be used to enter the tcl commands manually in an interactive session or, as used by ltk to access wish from another program. Every Lisp I know of, offers a function to run a program in a subprocess and to communicate to its stdin/stdout streams. The ltk function do-execute wraps these platform-dependant functions in a generic one. Its parameter is the name of the program to start as a string, a list with the parameters for the program. It starts the program as a subprocess of the Lisp process and returns a two-way stream to communicate with the program. To send some text to the program, its just written into the stream, and likewise output from the program can be read from the string.

All ltk widget creation functions actually create two objects: the CLOS object to represent the widged on the Lisp side, and the corresponding Tk object.

The root class of the ltk class hierarchy is the tkobject class. It has only one slot: the name of the object. In tcl objects are tracked by their names, very similiarly like symbols in Lisp. To represent all widgets the widget class is derived from tkobject. It adds the slots for the object being the master of the widget and the path string for the widget. As mentioned before, all tcl objects are referenced by their name, and all tk widgets have to be put in an hierarchy. This is represented by a path-like naming system. The name of the root object is just ``.''. Creating a frame named frame1 below it would lead to a path name .frame1. A button called button1 placed into this frame gets the pathname .frame1.button1. Both the naming and the path creation is automatically handled by ltk. To create both only the reference to the master is needed. In an after-method to the initialize-instance method of widget, the name is created as an unique string and the pathname is created by appending this name to the pathname of the master widget, or ``.'', if the widget has no master specified. The unique name is created by appending an upcounting number to the letter ``w''. Finally the method calls the create methode upon the new widget. This create method is, where the code interfacing with tk takes place. So to support new tk widgets, only a subclass of widget has to be made and a create method to be written.

Internally used special variables are:

*wish* The stream used to communicate with wish.
*callbacks* The hashtable associating widget names
*counter* The counter variable used to give widgets unique names (wn, where n is the counter variable, that gets incremented upon use).
*event-queue* If event messages are read while waiting for a data message they are buffered in that list.



Subsections
next up previous contents index
Next: Communication Up: LTK - a Lisp Previous: Window manager functions   Contents   Index
Peter Herth 2006-01-29