How do I retrofit a GUI to an existing C program?

Question

I've been working on a project of porting an old solaris CL program to run on Linux, and barring some unrelated hardware issues, that's finished. Now I want a GUI for it, so the user can choose among the various options with drop downs and check boxes, as well as some text input areas for options that aren't so restricted, like the filename. (The program is an internal tool to run some spectroscanners and store the results as CSV files. It handles all these options, runs the scanners and processes the info and stores it with the specified filename; I just want something nicer to use than CL.)

The only time I've seen something like this done was a PyGTK+ GUI with python bindings for the C code (I think that's what it was; that was my first semester co-opping and I didn't understand very much!). That's a bit more than I want to get into right now; is there a relatively easy way to do this? When I Googled I found SWIG (http://www.swig.org/index.php); is this a good way to go?

Answer 1

As others have said, Tcl/Tk is a good choice. There is a real risk you will outgrow the Tcl language, but that risk is mitigated by the excellent power and simplicity of the Tk windowing toolkit.

The other choice I would consider is wxlua. The reasons are that Lua is a language you will not outgrow. You might also prefer wxlua because it is based on wxwidgets, which will give you GUI a native look and feel. The original Tk had a rather strange and very non-native look and feel, but things are much better now, so this reason may not carry much force. You might look over the two GUI toolkits to see what appeals. A final reason you might prefer Lua is that it is easier to expose user-defined data types to the GUI and to scripts.

I would not consider alternatives such as Python and Gtk+, because of all the alternatives out there, only Tcl and Lua were designed from the start to be married to C programs.

You also ask about SWIG. Although it is superficially attractive, I recommend avoiding it. Both Tcl and Lua have very simple C APIs and you will learn more, understand better, and be in better control of your application if you learn to use the native API yourself instead of having SWIG generate code for you.

Answer 2

I have to second Tcl/Tk. I did exactly the same thing for legacy programs written in Fortran/C/C++. Since it's very trivial to write a DSL in Tcl/Tk, I ended up just adding an option for the program to output DSL (essentially Tcl commands written in procs) for tk program to eval. I've done this for a program with to do fairly complex graph animations on a tk canvas, that has options to save portion of the animation in mpeg in about 4 hours. People were amazed. It's completely portable as well. Tcl/Tk has simple, yet sophisticated event driven facilities (that's still unparalleled in its simplicity) to write GUI apps. You can use simple pipe to interface with legacy programs as long as it can read from standard input and write to standard output.

The huge advantage of this approach is that you don't need to link any GUI or additional libraries with your legacy programs, which is sometime impossible. The GUI and legacy program can be completely decoupled.

And that's about 10 years ago. Tk has evolved/improved a lot since then and gained native look and feel capability.

The major disadvantage used to be packaging standard-alone Tcl/Tk programs, which is largely solved now as well.

EDIT: DSL stands for 'Domain Specific Language' Extensions to the Tcl interpreter manifest themselves as new language keywords. Tcl has a fairly basic syntax, so this mechanism allows quite a lot of scope for extending the language. A good example of an application that does this with Tcl is Expect.