The problem - Tcl/Tk is perceived as dying.

Tk is, to a large extent, the public face of Tcl. And it is a face that could do with a little make-up. Professional Tcl/Tk developers know that Tk can be used to build GUIs that look good and work well across multiple platforms. And can be implemented in a fraction of the time of alternative languages.

But this counts for little if many users don't even know they are using a Tcl/Tk interface - Tk has been seen as such a liability that organisations don't publicize the fact they use it.

Worse still, the first experience many have of a Tcl/Tk application is of a poorly written application - either because Tk looks dated "out of the box", or because Tk makes it easier for non-GUI experts to build applications, and so increases the chance of a "less than professional" GUI being developed.

For example, consider one of the most widely distributed Tcl/Tk applications that is known to be implemented in Tcl/Tk - the "make xconfig" application in the Linux source. This application can (at best) be described as "dated". And Tkman - another widely distributed Tk application that could do with a makeover.

Abandon ship, or...?

Developers choosing toolkits to implement new projects are often ignoring Tk, in favour of native Windows, Java, wxWindows, and others. People using Tk now are seriously looking at getting rid of it for newer versions. Tk is perceived as a liability, and rightly so. Customers complain when applications don't look like other applications they are running, and that's the way most Tk applications look today.

We think these other toolkit options all have serious shortcomings too. Some of us have worked hard to tune Tk in our own apps to make it look right. It is possible. After careful analysis of the work that appears to be involved, we figured we'd be further ahead if we put a bit more energy into improving Tk to bring it back up to snuff, rather than each of us diddling with our own apps, or switching away altogether. After all, Tk still has a lot of amazing things going for it.

So what's the solution?

Rather than a patient that is "terminal" - we have a patient in need of a face lift. And perhaps a little Tender Loving Care.

The "Tk Revitalization" project was initiated at the Tcl2003 conference, with a view bringing the benefits already realized by a few specialist GUI developers, making them available as an "out of the box" experience for all Tk developers/users - and prepare a roadmap for the longer term.

The project will address three broad categories of issues

• technology
• process
• perceptions

Technology is the easy part - there's a body of knowledge as to how to tune the look of Tk applications, plus a number of good extensions available already. Of course, this might lead one to ask "why hasn't something already been done???"

This is where process comes into it.

One of the benefits of Tk is that it is relatively easy to work around its limitations. So specialists did just that, instead of co-ordinating an effort to resolve the underlying issues. But subsequent to the Tcl2003 conference, there is a broader recognition that something needs to be done, and a commonality of purpose to make it happen. And, at least from the members of the TCT present, there was the willingness to support this to the maximum extent possible.

That, combined with the donation of ProjectForum, Bitkeeper and mailing list resources, means that there is now the means to bring together a smaller group to facilitate the revitalization.

Addressing the perceptions will be more difficult. The ten-year old arguments about RMS and ESR's comments are perhaps not relevant, given that the aim is to create a "pull market" with technology decision makers. A rebranding exercise would break with the past, plus also recognise that the "Tk revitalization" is much more than Tk itself - more "the best of Tk and friends".

So - that sets the scene.

Visit the Project Roadmap for the next installment of this gripping saga ...

Posted at Aug 14/2003 07:29 AM:
David S. Cargo (escargo): Is there a way to define the problem more crisply? To provide a check list of the problems so that they can be debated, ordered, and solved? That's what we're working on here - Mark