Most computer users interact with their workstations primarily through some form of graphical user interface (GUI). In the world of Microsoft Windows, this interface is tightly controlled. The UNIX world, by contrast, offers a veritable smorgasbord of different GUIs with varying degrees of functionality. They range from minimalist window managers, such as twm, to large, capable tools, such as GNOME and KDE (K Desktop Environment). This article shows you how the Tcl/Tk scripting language offers a simple and elegant way to code GUI widgets with minimal effort.
Go Beyond what the Desktop Normally Does with Tcl/Tk
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I remember when I started the whole Linux thing back in 98, all the distros came with loads of Tcl/TK programs. It had been huge during the nineties, but had begun to wane, not leasy because the programs looked a bit clunky.
In many ways Perl today is the new Tcl: there are very few people started new projects with it, but it’s distributed with every copy of Linux as there are so many useful utilities written in it.
Frankly the claim that “this article shows you how the Tcl/Tk scripting language offers a simple and elegant way to code GUI widgets with minimal effort” is stretching the truth a bit: any mix of Python or Ruby and Qt or GTK is easier (for the modern developer) than Tcl/Tk. Hell, I’d even go so far to say that Qt/C++ is better.
Tcl/Tk was revolutionary for its time (Tk in particular), but anyone starting a new project these days would be better off using a scripting language interface to a modern library: Python, Perl or Ruby with Gtk/Gnome or Qt/KDE. It’s just as fast as doing Tcl/Tk, but Gnome or KDE gives you so much more than Tk does.
Except Gnome or KDE means you stay there. My Tcl/Tk application can go way more places. I use Perl for my web stuff. But I use Tcl/Tk for all my sysadmin stuff. If you haven’t used it in any depth you aren’t going to understand the richness of the language. It is really cool.
One thing I have to mention and that is the Tcl community is super friendly and helpful. I appreciate that a lot.
Tcl 8.5 is adding themeing to Tk (native l&f) and is going to add an object system to its core that is extendable. That should see the light of day this year.
As far as Windows goes, it has tcom and TWAPI that give you easy access to the internals of Windows.
The ability to easily pack the Tcl program into an EXE on Windows and a program on Unix is very nice as well.
This is by far the most fun I have had with a dynamic language.
Except Gnome or KDE means you stay there. My Tcl/Tk application can go way more places.
How about this compromise: Use the Tk widget set, with the much better environments presented by Perl, Python or Ruby? I have used Perl/Tk and Python with Tkinter, and had the benefit of using those powerful languages, and yet still managing to have the cross-platform GUI available. True, Tk doesn’t really provide a very “modern” GUI widget set, but it is useful and cross-platform.
On another though, if you use Python, you can use wxPython and have a cross-platform application. I do that all the time, writing one app that runs on both Windows and Linux.
Tk has its uses, I don’t think you’d do a large application on tk but small gui’s work fine.
I’ve used tkinter and it was REALLY easy to learn, compared to Gtk.
look at http://moodss.sourceforge.net/ (a graphical monitoring application): it is indeed a large application.
Why not Lua? Easily embedded in apps and the syntax is very similar to pseudo-code.
Damn Small Linux guys use Lua/Fltk and their apps look very nice.
http://distrowatch.com/weekly.php?issue=20060508#interview
Everytime I use a program written in Tcl/Tk I get zapped with a feeling of nostalgia.
http://en.wikibooks.org/wiki/Programming:Tcl
I wrote a young etrade’s dashboard in it. Try mixing that with expectk for a real scripting rush. Modern scripting languages haven’t brought anything really new to the party and can barely even replace it.
I thought Sun had buried it under a rock in the backyard somewhere so it wouldn’t compete with java, nice to see it still in play.
Well, last months, I tried various solutions, looked into Io language, Ruby, Python, and the scenario always seems to start the same way – some suggestion of my friend, to look at “easy” and cool gui toolkit for particular environment.
… and it always ends the same way … installing packages, solving dependencies, to find out, how BIG the distro is.
And in the end, I always realise, how I like the other way, the REBOL way – gui toolkit in 700KB, including integrated AGG http://www.antigrain.com vector library.
Rebol/View 1.3 is solid product, available for Win/Lin/OS-X, and while producing non-OS-compliant widgets, it has its own beauty.
Is Rebol non-bloated way a correct way? Well, there is many paths you can walk, but some of us like the easy way, and now also Ruby community openly claims, they try to clone Rebol/View. And that is why we have REBOL 3 effort undergoing (http://www.rebol.net ), to step ahead a bit 🙂
cheers,
Petr
I code REBOL apps full time, and it’s a joy being able to move between Linux and Win98/XP hardware with very few problems, except for fonts.
My daily coding box is a Mac, but REBOL runs fine there too. It’s wonderful to be able to code a complex application on the Mac and then run it without trouble on the WinXP box.
But REBOL is really not a fair comparison to Tcl. REBOL is more suitable for building entire coding/debugging/release infrastructures, not just simple GUI applications.
For those talking about ‘modern’ scripting languages like Ruby, you should know that
1) Tcl is still actively developed.
2) It’s still got some nice tricks up it’s sleeve. See, for example:
http://antirez.com/articoli/tclmisunderstood.html
(Skip to the ‘why is it powerful’ part if you already know the syntax)
and
http://journal.dedasys.com/articles/2006/03/06/ruby-vs-tcl
in which I compare Ruby and Tcl… and Tcl doesn’t come out badly at all.
There are some screenshots of modern Tk applications on the wiki at:
http://wiki.tcl.tk/13636
These also use the new Tile theming engine for Tk, which will probably be in Tk 8.5. I don’t think it really matters whether you use Tcl/Tk, Python/Qt, or Javascript/HTML/CSS (although Tk still has much to recommend it), but rather that you don’t use C++ or Java for GUIs.
I’ve done quite a lot of Tcl/Tk in the days when it was one of the major GUI players on Linux (’94? No Qt, no Gtk, just Motif and XForms). Yet better stuff came up and I didn’t touch my Ousterhout book for quite some time.
But recently I’ve done some work in this area again, and while I’d agree that the language looks rather simplistic and the GUIs show their age, there’s still quite a lot of hidden power behind that facade.
Agree, compared to syntactical monstrosities like Ruby and Perl, Tcl looks quite anemic and wordy at times (expr…). But due to the fact that it just has those simple rules and excels at string transforms, it’s pretty versatile once you actually start to program the interpreter. In this regard it’s quite similar to Lisp, yet more focused on strings than list/tree structures.
If you take a look at the Tcl Wiki, you’ll find several OO systems, all written in Tcl itself. And the resulting syntax manages to look pretty “native”, not as artificial as Perl does sometimes.
The interpreter is quite fast, the event handling mechanism is excellent and with Tile, the GUIs actually manage to look half-way decent.
As with Perl, Tcl has no big standards, so you’ll have to grab your additional widgets, your OO system and everything yourself. This requires a lot of work, younger langauges like Ruby and Java have a higher degree of standardization. Whether that’s wholly good or bad is another matter for discussion.
All in all, Tcl is worth a second look. Not the programming language panacea, but at least a source for some ideas…
I’m still using Tcl/Tk after about 15 years (That long? whoa!). I really like the newer languages, but they never seem to offer the stability, installability, transportability, and “workability” of Tcl mixed with Tk. Why use Perl or Ruby or whatever if they really are using TK widgets? They are still Tk widgets with the underlying tcl glue, yes? Or if they are NOT using the Tk subsystem, what about the transportability, installability?
Also important is the TIME domain. If you write it today, can you back transport to “obsolete” systems (customers are like that: they want you to use the hardware they have: bummer). Tcl/Tk seems to work pretty well for that. I rest easy knowing it will still work 10 years from now.
AND: tclkit has the solution for multiplatform distribution that just works. Your whole application and libraries and hardware drivers(if needed) in only two files to install on the customer’s system. Only one need be archetecture specific.
Oh, yes. And free, as in beer. (and freedom), and oh, yes: it gives me time to work on “celarien”