There are many things which can be configured about the TextTest GUIs, some of which are mostly a matter of personal taste. To this end, it is possible to have a personal config file where you place any entries that are supported by the config files (although it is advisable to stick to GUI appearance). This file should be called “config” and placed in a subdirectory of your home directory called “.texttest”. You can also place it anywhere at all and identify the directory with the environment variable $TEXTTEST_PERSONAL_CONFIG. (“Home directories” on Windows are formed either from the $HOME variable or a combination of the variables $HOMEDRIVE and $HOMEPATH)

You can edit and view these files by going to the “Config” tab in the static GUI, where you will also see the config files for the applications you're currently running on.

The look and feel of the GUI widgets themselves can be configured by providing a GTK configuration file. This file should be called “.gtkrc-2.0” and should be placed in the same directory the above “config” file, if you want it to only affect TextTest, or in your home directory if you want it to affect all GTK GUIs you might run. The syntax of these files is described, for example, at the PyGTK homepage.

You can also configure the contents of the toolbar via XML files placed in this directory. Such an XML file should be named to indicate to TextTest when it should kick in. For example:

The first element indicates the configuration module run (and any parent modules). The second should be "static", "dynamic" or absent. The file name should always end in _gui.xml.

As for the contents, the easiest thing is to look at the files in the source/layout directory and pattern-match. Note you only need to add extra XML sections, you don't need to copy these files, though they give you the names of all possible elements. For an example which extends the standard toolbar, look in the self-tests under GUI/Appearance/UserDefinedGUIDescription/personaldir.

By default the whole test suite will be expanded on starting up the static GUI. This can sometimes be awkward, especially for test writers who are only interested in a small part of the test suite. For them, it is best that everything starts collapsed so they can just view the parts that matter to them.

To this end there is a setting “static_collapse_suites”. This should be set to 1 to disable the automatic expand of the test suite. Instead, it will only expand the first level of suites/tests.

TextTest comes by default with four bars: all of which are optional: a menubar and toolbar at the top and a shortcut bar and status bar at the bottom. The menubar and toolbar are fairly standard and generally provide access to the same functionality.

The shortcut bar at the bottom allows you to create GUI shortcuts for sequences of clicks that you do regularly. This is the GUI shortcut functionality as provided by PyUseCase, which TextTest itself relies on, primarily for its own testing, but also to allow for this customisation possibility.

The status bar at the very bottom tries to indicate what TextTest is doing right now or has just done. The “throbber” at the far right indicates whether it is doing something: sometimes searching a large test suite for example may take a little time.

All of these can be hidden by default using the “hide_gui_element” entry, as above, see the table of config file settings for the key format. If you don't hide the menubar via this mechanism you can also show and hide them via the “View” menu.

There are plenty of configuration options in various tabs around the GUI, and all are identified with a label next to them. This label is used to identify them in the config file: take any label, make it lower case and replace all spaces replaced by underscores (“_”) and you have a way to identify the control in the config file..

Default values are changed by using the config entry “gui_entry_overrides”. For text boxes, simply provide the key as given above with the text you want as the default. For check boxes provide “0” or “1” as appropriate. For radio buttons form the key by concatenating the label with the label for the specific button you want selected, and providing “1” also.

In a similar way you can configure what options are presented in drop-down lists to the user, in the case of the text boxes. This is done via the “gui_entry_options” config file entry, which is keyed in the same way. For example:

[gui_entry_overrides]
show_differences_where_present:0
current_selection_refine:1
run_this_version:sparc

[gui_entry_options]
run_this_version:linux

This will cause the dynamic GUI saving tab not to automatically check the box for "Show differences where present", as in the example above. It will also cause the static GUI to include the version "linux" in a drop-down list for the "Run this version" text box and to set it to “sparc” by default. And finally the radio button on the “Select Tests” tab will select “Refine” instead of the default “Discard”

There is also the possibility to enable and configure GTK's entry completion functionality. This is separate from the drop-down boxes and works by guessing what you're typing based on what has been typed before. It is enabled by default, and will by default match based on the beginning of what has been typed. To disable it, set “gui_entry_completion_matching” to 0. To cause the matching to occur on any part of what has been typed, set the same entry to 2. If you want previous matching text to be automatically inlined into what you're typing, set the “gui_entry_completion_inline” entry to 1. Note that this can be confusing if you aren't used to it!

Additionally, you can “hardcode” completions that should always be present, by adding to the config file list entry “gui_entry_completions”.

The colours for the test tree view (left window) and the file view (top right window under Test tab) can be configured via the GUI dictionary entries “test_colours” and “file_colours” respectively. These are keyed with particular pre-defined names for the different test states: to see what they are, look at the default values in the >table of config file settings. The values should be text strings as recognised by RGB files.

The toolbar actions generally have keyboard accelerators, whose values can be seen from the menus which also contain them. These can be configured via the “gui_accelerators” dictionary entry. The keys in this dictionary should correspond to the labels on the relevant buttons, and the values should be for example “<control><alt>r” or “F4”. If in doubt, consult the format of the default ones in the >table of config file settings. The values should be text strings as recognised by RGB files.

If you find the TextTest window sizes to be inconvenient you can also configure this. There is a config file dictionary entry “window_size”. This has various keys, which can be prefixed by “static_” or “dynamic_” to make them specific to the particular GUIs if desired.

“maximize”, if set to 1, will maximise the window on startup.

“height_pixels” and “width_pixels” give the window an absolute size at startup (not recommended outside personal files!)

“height_screen” and “width_screen” give the window a size as a fraction (not percentage!) of the size of your screen.

“horizontal_separator_position” and “vertical_separator_position” allow a default configuration of where the pane separators start out, also as a fraction of screen size.

Naturally, when you press Quit in the GUI it will try to clean up everything it has created in terms of both files and processes. For what happens to the temporary files created, see the section on the temporary directory.

As we've seen above, it is quite possible to start many different viewers and editors from TextTest and many different dynamic GUI runs from the static GUI. If all of these had to be closed by hand it would probably be cumbersome – so the default operation of TextTest is to find all of these processes and kill them. On UNIX, they will be sent SIGINT, SIGTERM and SIGKILL with a pause in between. On Windows, they will be terminated with “taskkill” which tends to be fairly final. If for any reason the tests don't terminate as rapidly as they should, pressing Quit a second time is recommended.

It can be useful to configure a questioning dialog such that TextTest will ask you before killing such processes. This is the purpose of the “query_kill_processes” config file entry. This is a composite dictionary whose keys are “static”, “dynamic” or “default” (this last for both static and dynamic GUIs) and the values are patterns of “process names”: i.e. names of editors, viewers, the dynamic GUI etc. For eaxmple:

[query_kill_processes]
default:.*emacs
static:tkdiff
dynamic:texttest.*