While fans of wxWidgets, Qt, GTK+, and other GUI toolkits often deride Tk as "old-fashioned", a good case can be made that it's merely mature. Well into its second decade of successful application, Tk remains the most reliable cross-platform GUI toolkit, besting even Java's AWT in its effective coverage. Beginners also find it easier to start with Tk than any other system, with the possible exceptions of rather hermetic and platform-specific technologies, as well as members of the *Card family.
Why has Tk aged so gracefully? It enjoys several specific technical advantages, discussed below. At a higher level, it seems increasingly likely that Tk is better off for being object-based, but not object-oriented. [Explain. Todd Coram makes the point that OO limits tagging to clumsy static kinds based on RTTI and multiple subclassing--yuck. Maybe we can get Todd to write more.]
A big difference between Tk and Java's AWT/Swing is that Java provides not just a set of widgets, but also the entire infrastructure for creating new widgets, drawing graphics (manipulating individual pixels), etc. This means Java is very, very complicated, but allows you to create new widgets without needing to code in C. Tk, on the other hand, will usually require you to code in C to create an entirely novel widget' (but, it is actually quite rare that this is needed, and this is possibly why Tk is so much easier to use -- many, many so-called 'new widgets' can be implemented simply as mega-widgets, without any C).
ulis 2002-01-08:
It is possible -and easy- to write some megawidgets entirely with Tcl and Tk. An example is Hugelist [L1 ] which implements a list box that can handle more than 1,000,000 items without CPU or memory penalties.
For how this is possible, see: Mass-widget.
Yes, ulis, that's what the previous contributor said - that megawidgets can be written in Tcl/Tk. But that to create unique new widgets , one needs to go to C code because Tcl does not, at the script level, exposure APIs for generating the appropriate X transactions.
ulis 2002-01-09:
OK. What are these X transactions and why are they needed? (For my megawidgets I needed no more than Tcl & Tk commands)
unknown: Well, why do you think the high performance graphing widgets of BLT are written in C? What about the 'Vu' widgets? All of these things could (probably) be written in Tcl by manipulating lines and pixels on the canvas widget, but that would not be very practical.
ulis: Hmm... Performance is complex and not the prerogative of C. A careful design can make megawidgets in plain Tcl/Tk behave more faster than C widgets (under some circumstances). For example, the Hugelist can load, move and resize 1000 times faster than the Tk Listbox when 1,000,000 items are involved. I conclude that all two possibilities are useful.
DKF 2003-01-09:
The main thing that you can't do with Tk as it currently stands is clipping (to anything other than the window.) If you could define an area (rectangular or otherwise) within which an object is drawn, then you'd be able to synthesize virtually any widget using a canvas. Well, maybe it'd take extra work to get things like focus and binding handling working nicely, but it'd be possible to fix them. It is clipping that is the major operation that is missing.
BTW, Swing uses a sophisticated drawing model on top of what is effectively a canvas - though a canvas without all Tk's nifty features, to build itself on top of the basic display primitives offered by AWT, so it can be done. Mind you, Java2D - the drawing layer used by Swing - is a slow pig unless your computer is unreasonably chunky...
AMG: The Swing drawing model is very low level. Widgets need to provide code for redrawing themselves on Expose-type events. For an old example (probably not compatible with new versions of Java), look at the custom widgets (Chart, My*) in my rlemonitor program [L2 ]. I might move the URL someday; if this link breaks please fix it or remind me to do so. For a screenshot see http://ioioio.net/screenshots/app/rlemonitor.png .
