Tcl and Tk

Tcl stands for Tool command language. It is really two things: a scripting language, and an interpreter for that language that is designed to be easy to embed into applications. Tcl and its associated X windows Toolkit, Tk, were designed and crafted by Prof. John Ousterhout of the University of California, Berkeley in the year 1988 [246, Preface]. The idea was to build a general-purpose scripting language as a C library package that could be reused for many different purposes in many different applications. This early vision imagined that applications would be large bodies of compiled code and a small amount of Tcl used for configuration and

4.1 Introduction

high-level commands. But it soon turned out that it was possible to write entire applications in Tcl. This is because of the Tcl/Tk shell, called wish, that provides all the functionality of other shell languages, including running of other programs, plus the ability to create a Graphical User Interface. Tcl and Tk have succeeded “beyond the wildest dreams” of Professor John Ousterhout [246, Preface] and today there are thousands of Tcl applications in existence or under development.

Tcl provides generic programming facilities, such as variables and loops and procedures, that are useful for a variety of applications. Furthermore, Tcl is embeddable. Its interpreter is a library of C procedures that can easily be incorporated into applications, and each application can extend the core Tcl features with additional commands for that application.

The most useful extension to Tcl is Tk: Tk extends the core Tcl facilities with commands for building user interfaces, so that one can construct Motif-like user interfaces by writing Tcl scripts instead of C code. Like Tcl, Tk is implemented as a library of C procedures, so it can be used in many different applications. Tk extends the built-in Tcl command set with additional commands for creating user interface elements called widgets, arranging them into interesting layouts on the screen using geometry managers, and connecting them with each other, with the enclosing application, and with other applications. Individual applications can also extend the basic Tk features with new user-interface widgets and geometry managers written in C.

Together, Tcl and Tk provide a lot of benefits to application developers and users. The first benefit is rapid development. Many interesting GUI applications can be written entirely as Tcl scripts, using the windowing shell wish. This allows one to program at a much higher level than would be possible in C or C++, and Tk hides many of the details that C programmers must adress. Another reason for rapid development with Tcl and Tk is that Tcl is an interpreted language. Using a Tcl application such as wish, one can generate and execute new scripts on the fly without recompiling or restarting the application. This allows to test out new ideas and fix bugs rapidly. Since Tcl is interpreted, it executes more slowly than compiled C code, of course, but modern workstations are surprisingly fast.

As a scripting language, Tcl is similar to other UNIX shell languages such as the Bourne Shell (sh), The C shell (csh), the Korn Shell (ksh), and Perl. Shell programs allow the user to execute other programs. They provide enough programmability (variables, control flow, and procedures) to let one build complex scripts that assemble existing programs into a new tool tailored for the needs and wishes of the programmer. Shells are good tools for automatic routine

4 XDSi - A Graphical User Interface for XDS and beyond

chores.

It is the ability to easily add a Tcl interpreter to an application that sets it apart from other shells. Tcl fills the role of an extension language that is used to configure and customize appli-cations. There simply is no need to invent a command language for a new application. Instead, by adding a Tcl interpreter, one can structure an application as a set of primitive operations that can be composed by a script to best suit the needs of the users. It also allows other programs to have programmatic control over the application, leading to suites of applications that work well together. General information about Tcl and Tk can be found in [247] and [246]. There are already GUIs for crystallographic software written in Tcl and Tk, e.g. CCP4i [248;249].

4.2 XDSi

As can be seen in figure4.1, the main window of XDSi consists of two parts: the upper one is where the user gives inputs like the directory where he wishes to get his results, where his data set(s) is/are located and what mode of operation he wants to start. In addition status information is given about what job is currently running on what data set and some of the partial results like spacegroup and unit cell parameters are displayed. The lower part is a simple text window where textoutput of running programs can be read in realtime.

As mentioned above, XDS reads its instructions from the file XDS.INP. A cutout of such a file can be seen in figure4.2. Normally, the user has to change almost all of the values that can be seen in figure4.2for each data set that he wants to process with XDS. XDSi uses information stored in the header of the image files to create an appropriate XDS.INP file. So the user just has to choose the detector used for data collection (different detector types demand entirely different additional options in XDS.INP) and point to the first frame of his data set that he wants to be processed (XDS mode and XDS POINTLESS mode) or tell XDSi the directory containing all the data sets (XDS Fullauto mode) he wants to be processed. XDSi “counts” the frame number of each data set provided, reads the needed information from the image header and writes an XDS.INP according to the detector used for data acquisition. Currently two detector types are supported: PILATUS 6M Pixeldetector and MAR-CCD.

After that the user can select between three different modes of running XDS: If he chooses XDS mode, XDS will be run as if used without XDSi. Control parameters in XDS.INP can be changed in the "View and change values in XDS.INP" dialogue (see figure 4.6). If he chooses

4.2 XDSi

Figure 4.1:The main window of XDSi is separated into an upper part for inputs and status information and a lower part for displaying output text of currently running software in realtime.

4 XDSi - A Graphical User Interface for XDS and beyond

Figure 4.2:Cutout of XDS.INP for PILATUS 6M detector.

XDS POINTLESS mode, XDS will be run up to INTEGRATE in spacegroup one, POINTLESS will be used to determine the spacegroup of the underlying crystal lattice and XDS will process the data set in the spacegroup determined by POINTLESS (see section4.2.3for details). IfXDS Fullauto modeis chosen, XDSi will runXDS POINTLESSfor each data set consisting of more than 100 frames in the given directory and all its subdirectories. InXDS modeplots representing the most informative data of the XDS result files can be generated, inXDS POINTLESS mode andXDS Fullauto modethey are always generated. figure4.3gives an overview of the possible scenarios using XDSi.