Arjen Markus (31 december 2002) The purpose of this page is to discuss the following question:

   I have a nice (C, Fortran, ...) program and I want to develop a GUI for it.
   What options do I have?

Of course this depends on the type of program. Let us sum up a few types:

• Small batch jobs: The program reads an input file, does a few calculations and after several seconds, it gives an answer (on screen or in a file)
• Large batch jobs: The program reads an input file, does its calculations but requires several minutes or hours to produce an answer (on screen or in a file)
• Interactive programs: The program is highly interactive, but reads its data from the command prompt
• Mildly interactive programs: The program is mildy interactive, it reads a few files or data it asks for, does a lot of calculations requiring noticeable time and produces the results.

Under the assumption that you do not want to rewrite the entire program, here are some options:

---

Small batch jobs:

The part that requires a GUI is the creation of the input file or better the manipulation of the input data and the presentation of the results.

• The easiest way to do it is to create a GUI with Tk that prepares the input data and either calls the program via exec or open.

Pointers: exec, A poor mans GUI

• A (slightly) more involved way is to turn the program into a subroutine that can be called in Tcl. This subroutine must accept the input data and return the output to the caller.

Pointers: Critcl, SWIG

---

Large batch jobs:

As the calculations probably take too long, the best option is:

• Create a GUI for the input file
• Execute the program via exec in the background
• Pick up the results when it is finished

This does not need to be a single GUI, you can split up the tasks.

The nice thing about this is, that the original program does not need to be changed.

Pointers: exec, A poor mans GUI

---

Interactive programs:

When the program displays a prompt and wants to have information all the time, you have basically two choices:

• Provide the input via such programs as expect or expectk. The program will run as a separate process and does not need to know that it is running under control of another program.

     Simpler solutions of that type: [Managing Fortran programs], [FORTRAN via open pipe]

• Isolate the calculations and turn them into separate Tcl commands. The drawback of this solution is that you must change the program itself. The good news however is that it will be very easy to extend the program's capabilities, as Tcl would then provide the glue needed to put the pieces together instead of some complicated, fixed logic.

Pointers: Critcl, SWIG

---

Mildly interactive programs:

This type programs would ask you a few questions first and then start to work. Perhaps it will ask for a few more data later on. They fall between the categories of batchwise and interactive processing. The solutions can be either way. For instance:

• If the program asks input on the command-prompt and then goes off, simply prepare an input file via a separate GUI, pass the data via a redirection (see exec and open for details) and pick up the results when done.
• If the program will come back later, it depends: are the questions foreseeable - just prepare another set of data. If not, try the expect approach.

Note on event-driven versus interactive programs

You might think that an interactive program can easily be converted into a GUI. Well, you are wrong: interactive programs normally wait in a loop to read a command, process the command and then go wait for a new command. In technical terms: it is a procedural set-up. Everything happens in a predefined order.

In most GUIs the processing of commands is delegated to small routines that have an existence of their own (that is, they try to share as little state information or data as possible, working only on what they need). The order in which they are called, depends entirely on the user (and on the underlying system).

So, this event-driven approach requires a different way of thinking and programming. The two approaches do not necessarily conflict, but they are certainly not natural allies.

The solutions presented above try to avoid major redesigns of the whole program as much as possible.

---

LV If Tk came with (or at least if not with Tk, some how simple to obtain) something to do what zenity [1] does, except cross-platform, it seems to me that would be a nice demonstration of Tk's power.

---