The one real argument for Tcl/Tk

What happens when you want to work on a software project with the following requirements: If you're having trouble imagining such a thing being necessary, consider the concept of a CD-ROM demo with a front end program that autoruns under Windows (and would under Linux if such a feature existed.) It doesn't need to do much other than let the user select from listboxes, see some pictures, push some buttons and finally launch some applications. Naturally, the source to the app would be somewhere on the CD if the app included GPL'ed software.

My immediate thought was Qt/Embedded, which has some pretty glorious features for a low-footprint API and is pretty easy to learn as long as you can handle C++. The level of features you can include in a Qt/Embedded program with no dependencies could be seen in the early binary demo of Konqueror Embedded, before it was declared too primitive and removed. It was a complete web browser with Javascript, style sheet, and image viewing capabilities and it fit into 2MB with no dependencies. But to develop Windows applications, even free software, using Qt, you have two choices: pay upwards of $1000 for access to the Windows version of the SDK, or force the end user to install Cygwin (a kind of Unix emulation environment) on his machine prior to running your app.

I ran through some other choices but all of them ran afoul of one or another of my requirements, to wit:

After exhausting these possibilities, one of my Google searches turned up Visual Tcl, which runs as well on Windows as it does under Linux. I experimented with it, and found it too limited in some ways for what I wanted to do (change layouts at runtime, alter certain properties that VTcl appears to support but doesn't, etc.) I was going to have to learn Tcl anyway to do what I needed to, so I resigned myself to writing everything by hand. There was also the problem of needing a Tcl interpreter on the disk, not the end of the world but kind of icky. Then I found FreeWrap, which is basically the Tcl interpreter with support for virtual zipped filesystems included. It embeds your scripts and support files in a copy of itself (or the Windows version of itself) and the result is a single executable for each platform with no dependencies. It doesn't need to be installed and can be run from a read-only medium with no use of temp directories or other disk writes. In short, it just works.

Well, Tcl has kind of foundered in recent years; ActiveState doesn't seem to be able to decide whether they want it to be free software or a commercial product, and let's face it, it's kinda ugly. Ugly code and ugly 1980's style Motif-like interfaces are what I think of when I think Tcl. It's so backwards it supports GIF but not PNG natively. This can raise patent issues unless you use run-length-encoded GIFs, which I've done so far, but they're big compared to PNG or JPG. There is a Tcl extension called Img which will handle JPG and PNG images, but using it requires you install libjpg and libpng, which would violate requirements 2 and 3. I could build a new Tcl interpreter with libjpg and libpng statically linked, but that would require Visual Studio on the Windows side which breaks requirement 5. (I'm now looking into using mingw to crosscompile a Tcl interpreter with Img and other extensions built-in, like ActiveState's ActiveTcl only not licensed stupidly.)

On the good side, once you learn to deal with its odd syntax it's easy to do common UI things like mouseover visual cues, context-sensitive popup menus, loading and swapping images, and creating and destroying option dialogs. You don't have to worry about memory management and its weird syntax can actually be thought of as crudely object oriented in a similar sense as Visual Basic. Instead of object.method and object.property you have object method and object configure -property to set and object cget -property to get. And both would be crippling first languages for a new programmer to learn. But it's more powerful than VB, at least. It's kind of like the language I would have loved when I was 12 years old and writing in Commodore BASIC -- no, wait, that was Forth. Unlike most other free toolkits, I've managed to get past the learning curve using only a few references: the FAQ and manual at tcltk.free.fr, and George Staplin's tips on swapping images. And its version of foreach is insane.

In the end it turned out that demo project was unnecessary, but lately (thanks largely to Disk2FDI which allows me to read in my old Amiga disks on the PC) I've started playing with the idea of a CD containing a bunch of old games and the emulators to play them. Since I run Linux on my own machine but Windows on shared machines, it'd be nice to have one CD that works for both. And once you recognize that Tcl's defaults look awful and put a little time into design, you can make an interface that looks at least 1995 instead of 1988. Tcl's interpreted nature makes it pretty easy to add and debug modules to support other emulators as well. You don't even need to rewrap the executable since Tcl will happily evaluate any random data it reads as a Tcl program if you tell it to. Here's a few early screenshots of the project:

original interface
under Linux/KDE
using MAME module
under Linux/KDE
original interface
on a Windows box

Already it has "skins", tabbed config dialogs and a simple HTML help system. I expect I'll post it when I'm done, less any materials I don't have the rights to distribute such as logos. It will be of fairly limited use, but as far as I know it will be the only emulator front end to date that works without installation under both Linux and Windows.

And that, in a nutshell, is the first legitimate use of Tcl/Tk I've found that isn't satisfied by any other language/API combination I know of. I hope someone else fixes their issues (probably Qt/Embedded, since they have only the licensing issue to deal with) because Tcl is a pretty rough language to deal with, but as long as you think of it as a crossplatform equivalent to QBASIC it's not too unpalatable.

Back to home page. Updated February 2002. webmaster@kudla.org