4.6. Integrating SpecTcl in your experiment

4.6.1. SpecTcl's startup sequence

SpecTcl's startup sequence allows you to tailor several aspects of the program. Each phase of the startup sources one or more Tcl scripts that allow you to tailor the behavior and appearance of SpecTcl. Startup has three phases:

1. Pre-display initialization. The SpecTclInit.tcl files are located and read in. For most users, the main purpose of this phase is to set the value of the Tcl global variable DisplayMegabytes. This variable controls the size of the display shared memory region in Mbytes. (An MByte is 1024*1024 bytes).

2. Tcl/Tk interpreter initialization. In this phase, the Tcl interpreter has been created, but not completely initialized. In this phase, SpecTclRC.tcl scripts are sourced. SpecTclRC.tcl scripts have available almost all of Tcl/Tk and therefore can be used to create a SpecTcl graphical user interface. Tcl/Tk's concept of stderr has not yet been established however so error output from these scripts will not appear. We recommend that you debug SpecTclRC.tcl scripts by first sourcing them into a completely initialized SpecTcl so that you can see error messages from your scripts as you debug them.

3. Stdin redirection. Many users run SpecTcl with stdin redirected to a setup script. This script is run in the full Tcl/Tk initialized interpreter, so error messages will be visible on the SpecTcl TkCon console if that is used or on the terminal window from which SpecTcl was started if not.

Pre display initialization scripts are called SpecTclInit.tcl While these are Tcl scripts, they are run in a very early stage of the Tcl/Tk interpreter startup, and therefore should really only be used to set values of SpecTcl global Tcl variables. The following global variables may be of interest:

In addition, SpecTcl itself creates a few global variables. The most important of which for startup scripts is SpecTclHome which is the path to the SpecTcl installation that is being run.

SpecTcl's scripts are cumulative. This means that there are several locations in which scripts are searched for and all matching scripts are run. Configuration scripts are searched for in order:

1. A directory in the SpecTcl installation.

2. The user's home directory

3. The current working directory at the time SpecTcl is started

4.6.2. Writing a SpecTcl Startup scripts

In addition to setting up a common graphical user interface, users of SpecTcl often have a file that loads an initial set of definitions. These definitions may include:

• Non-tree parameter definitions

• Changes to tree parameter definitions from initial programmed defaults

• Tree variable modifications

• Spectrum definitions

• Gate definitions

• Gate applications

4.6.3. Adding GUI elements to SpecTcl

When SpecTcl starts, several Tk toplevel widgets are displayed:

• The default toplevel named . is created and displayed. The default SpecTclRC.tcl startup scripts fill this with a few buttons laid out in a vertical strip. The figure below shows the button bars from SpecTcl-3.1 (on top), and that of SpecTcl 3.0 and earlier (on the bottom). Note.

  Figure 4-3. The SpecTcl button bars

  

• The TkCon console that was written by Jeff Hobbs of ActiveState is opened in a top level window called .tkcon. This window provides a command console for SpecTcl that supports command recal, editing Tcl syntax hightlighting as well as a bunch of menus that give access to many other nice features. TkCon looks like the figure below:

  Figure 4-4. The .tkcon window

  

• A tree parameter graphical user interface. This will either be the tree parameter Gui written by Daniel Bazin or the new folder based graphical user interface written by Ron Fox. Both of these GUI windows are called .gui, and are shown in the two figures below:

  Figure 4-5. 3.0 and earlier Tree Parameter GUI

  

  Figure 4-6. SpecTcl 3.1 and later Tree Parameter GUI

  

You can customize SpecTcl's appearance by adding Tk widgets to any of these windows, or you can create a new toplevel widget of your own and build a Gui within it. Consider the following script:

proc openEventFile {} {
    set name [tk_getOpenFile -title {Choose an event file} \
		  -defaultextension .evt                    \
		  -filetypes {                             \
		      {{Event files} .evt             }    \
		      {{All Files}    *               }}]
    if {$name ne ""} {
	catch {stop}
	attach -file $name
	start
    }
}
proc fileButton top {
    return [button $top.readfile -text {Read Event File} -command openEventFile]

}

toplevel .newtop


foreach toplevel [list . .tkcon .gui .newtop] {
    set button [fileButton $toplevel]
    pack $button
}
                

This example builds a button for each of the SpecTcl GUI windows, and a new toplevel as well. The button, when clicked will graphically prompt for an event file that, when selected, will be analyzed by SpecTcl.