Tk Revitalization: Project Roadmap - *** THIS FORUM IS ARCHIVED ***

Key Pages

As with any GUI project, it is important to get regular feedback. This is especially so when cross-platform issues are to be considered.

So it is important the project proceeds gradually but consistently:

changes before Tcl/Tk 8.5 will need to be an add-on
they can be part of Tcl/Tk 8.5 but optional
they should be the default for Tcl/Tk 9
changes after 8.5 can leverage new core functionality (e.g. ensembles)
changes before Tcl/Tk 9 will need to be backward compatible

To use a sporting metaphor, it will be important to "kick goals early". This will both raise the profile of the project, and show that there is a real commitment to change.

There are a number of Tcl-only changes and extensions that could make an early, significant impact:

changes to widget options, fonts and colors (e.g. Brian Griffin's paper from Tcl2002)
Tcl-only widgets (e.g. such as BWidgets)

It is suggested the first phase contain three deliverables, each building upon the previous

a pure-Tcl package that uses widget settings (options/fonts/colors) to improve the look of existing applications
an update that adds the Tcl-only extensions
another update that adds some key compiled widgets (e.g. tktreectl, busy) for selected platforms (Windows, Linux and possibly MacOSX)

The problem with BWidgets (and other widget sets like iWidgets) is that there is a certain amount of baggage that will need to be discarded. For example,

a number of the BWidgets duplicate functionality now in the Tk core (e.g. title frames and paned windows) - these will need to be excised.
option/argument processing should be cleaned up, to make consistent with other Tk widgets
use of the packer replaced with the grid geometry manager

There will need to be example applications to demonstrate the new look/feel. Since the early releases will be aimed at developers, it may be a reasonable approach to give tools such as tkinspect and tkcon a makeover and include them as an example, along with the ancient Tk demonstration program (which should be brought up to date too).

Here is a suggested timeline, including some specific deliverables.

Uploaded Image

Posted at Aug 06/2003 12:59 PM:
Michael Lenaghan: I think you'd have to expect the introduction of a beefed-up 8.5 to delay the introduction of a 9.0. The introduction of so many new widgets is likely to spur a) bugs and b) requests for small changes. I presume it would take a while to sort all of that out.

Posted at Aug 13/2003 09:16 AM:
DGP: I've started a topic on the TCLCORE mailing list about setting a release schedule for Tcl/Tk 8.5 releases. Can anyone comment whether the Tk revitalization project will be able to deliver its proposals for changes to Tk 8.5 in time for an 8.5a2 release around November 1, 2003? Good question... Steve and I are discussing schedule stuff, so hopefully have an educated guess soon. - Mark

Posted at Aug 22/2004 06:57 PM:
Peter Newman: Tk's badly in need of revitalisation, because right now (as far as on-going development goes), it's stone cold dead. But the changes suggested on this page, whilst worthwhile on their own merits, will only make it deader.

Tk is dead because it's one monolithic app. As such, it exceeds the resources of a single programmer to understand or modify it. Since Tk is open-source, it's on-going development depends on individual programmers, working for free, incrementally extending it. But right now - and for the last five years or so - Tk is simply too big and complicated for an individual programmer, with limited time, to do this.

Which is why it's just not happening - and why programmers who do want changes re-write the widget concerned from the ground up - rather than upgrading the existing widget.

To fix this, we need to break Tk up, so that every widget is a single, stand-alone piece of code, that may be separately compiled (into a stand-alone dll/so). Presumably there'll also have to be a 'core' library for shared features like the Options Database.

Forget about the enhancements listed on this page. They'll only make things worse. Let's smash Tk up. Then the enhancements will come fast and furious - just as they did in the beginning.

Posted at Aug 23/2004 07:38 AM:
LV: Peter, it doesn't seem likely that any of the people seeking a new look for Tk are going to divert their time into refactoring and reorganizing Tk. I would expect that, if this is seen as necessary by one or more programmers that they would be the ones to jump into the work.

However, you are one of the few people, to date, that I've heard advocating that approach. I'm not saying that you are wrong - just that if you want to see something like this, then you probably will need to start on it on your own, and then, perhaps after you get some of the infrastructure built, others will see the benefits of what you are advocating and join in.

I myself can't envision how the changes you discuss could do anything more than make tk more difficult to maintain and extend. But then, I've not much experience on the 'innards' of Tk.

What other graphical user interfaces do you know of which provides functionality such as you envision?

Posted at Aug 25/2004 07:14 PM:
Peter Newman: I don't know of any other GUI that takes this approach. But then I haven't really looked. But the basic problem still seems to be that Tk is just so big and complex that individuals wanting to change things just get overawed and give up. This is the fundamental problem with Tk - not the presense or absense of this or that feature.

And obviously, as you pointed out, even breaking it up into more manageable (eg; widget-sized) clumps, still seems more work than anyone can get exited about.

But there are a lot of people who've spent a lot of time implementing new widgets. Iwidgets, Bwidgets, tkhtml, treectrl, tablelist, hugelist etc. The list just goes on and on. So there doesn't seem to be any shortage of people wanting and working to imrove Tk.

But how much of the work that they do replicates functionality that's already in the core. It's often easier to write a new widget, from the ground up, rather than upgrade/extend the existing one. The core remains static. And it's limitations (such as lack of theming/styling,) remain in-place.

The Tk styling project on Sourceforge is an example of this. As far as I can tell, the guys are re-writing some of the core widgets from the ground up. They're essentially re-writing Tk. The project's great. The #1 feature missing from Tk is IMHO theming. But surely it would be more efficient if themes could have been added to the existing widgets.

So I still feel that breaking the Tk core up in manageable, stand-alone chunks is the only way to save it. But I don't see it as being an easy task. And I agree with you, there seems to to be little enthusiasm for doing this.

But then, that's the fundamental problem with Tk and Tcl. The single, monolithic core approach is self-defeating. As the core becomes bigger, it becomes harder and harder to enhance and upgrade. Eventually, it stagnates and dies.

It's just a case of switching from a single monolithic core approach. To one centered on small, easily maintained modules - each with it's own well-defined, well documented API.

It's probably too late to save Tk, but perhaps new widget writers like the Tk styling project can bear Tk's fate in mind. And keep the code modularised, well-documented, and easily maintainable.

Posted at Aug 28/2004 10:58 PM:
Brian Griffin: I just don't see it. I don't see what the monolitic architecture has to do with it. What I believe the real problem is that Tk is not extensible like Tcl is. The only way to create new widgets is by writing is C which is painfully difficult, or writting complex proc's which is also difficult to write and maintain. What Tk needs is an OO mechanism that matches Tk's OO nature. Ideally, this mechanism would allow people to compose new widgets using the core intrinsic widgets, and make them as easy to use as intrinsic widgets. This can be (somewhat) accomplished today with extensions like incrTk, SNIT, and possibly XOTCL, but the problem is that these extensions are not part of the core. Once people can create new widgets using Tcl code, then you'll really see things advance rapidly. And these widgets would be modular since they'd just be Tcl packages. The Tk core should then continue looking at fundamental building blocks only; things that can't be composed from existing intrinsic widgets.