user interface - 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

This sounds like exactly the job Tcl/Tk was designed for. It has a very simple C API that allows you to register commands with a callback. If you use the command in a Tcl program, it will invoke the callback and provide a mechanism to convert the arguments between a Tcl list (native data structure) and an ARGV style array of char*.

It was designed specifically to be easy to retrofit this sort of wrapper to command-line driven C programs. There are also a variety of other modes you can use to interface the interpreter as well, and it is easy to embed into programs as a scripting language. From memory the available interfacing mechanisms are:

• Register commands in the Tcl interpreter
• Embed a Tcl interpreter in your program and use Tcl as an embedded scripting language (possibly including registration of commands and callbacks to your program)
• Spawn a process with a full-duplex pipe and send commands via stdin/stdout (you can also attach an event handler to the pipe which is invoked when data is available)
• Less Tcl specific mechanisms such as fork/exec or connection via sockets.

Ousterhout's book Tcl and the TK Toolkit is a bit dated but has a good guide to the C API. Welch's Practical Programming in Tcl/Tk is the other classic Tcl/Tk book and is updated more frequently. There are also several other books and quite a lot of electronic resources on the internet. Some good starting points are: Tcl tutorial, TK tutorial, Tcl advocacy site (might be worth perusing to help you decide if you want to go down this route), Tcl/Tk Wiki and of course Stackoverflow.

TK will give you a straightforward GUI and is very easy to learn to program - if a little simplistic. It's not as ugly as it used to be if you take some time to tweak the appearance or use a theming engine such as Tile.

As Norman Ramsey points out (+1), another alternative with a simple C API is Lua. Both have advantages and disadvantages. The principal strengths of Tcl are the simple and cleanly integrated TK toolkit and good, mature support support from third party libraries (e.g. Tix). The main strength of Lua is that the language is much nicer but there is no standard GUI toolkit, so the UI is not as nicely integrated. Lua also has much better support for threading in the interpreter, having been designed for this from the ground up. However, if you're wrapping a legacy C/unix application, this is unlikely to be a significant feature.

WXWidgets is considerably more complex than TK and carries more runtime baggage but has a richer feature set.

If you have genuine reason to think that your scripting project will grow into a larger application you might consider Lua. However at a larger scale you're into a substantial development project and Python or Ruby start becoming viable options. As the project gets larger wrapping the C codebase will be a smaller portion of the overall project and third-party library support will be a bigger consideration.

If you go with Tcl and discover your project gets a life of its own, consider embedding the Tcl interpreter and re-casting the application as a plugin API that people can hook their own scripts into. Extra features can be done as scripts and possibly fobbed off onto third parties for maintenance. One of the advantages of a system with a built-in scripting language is that you personally do not necessarily have to implement features. People can write their own extensions in the scripting language or get third parties to do it for them.

SWIG is designed to generate wrappers around libraries. It parses the header files and generates a glue layer that presents a native API in the target language. To use it, you would have to re-factor your program into a library.