Tcl/Tk 8.5 First Impressions.

The official 8.5.0 release of Tcl/Tk was released a couple of days ago, after several long years in development. I've updated my Busy Developer's Guide to reflect that version.

All in all, this release is a very good thing on many levels, and the people who put so many hours of work into it deserve thanks and congratulations. It's a significant release both due to the improvements in Tcl itself (which at a day-to-day level remove some real annoyances), but particularly at the Tk level. With the inclusion of the themed Tk widget set, it marks the first time that the core version includes pretty much everything needed to make a non-embarassing post-1990's graphical user interface. While it's probably unfortunate that there was so much distance to come from behind, that doesn't undermine the significant step that was taken. Again, this is a milestone.

Now that it's official of course is the time where all the armchair quarterbacks start taking a serious look at it, when it would have been more helpful if they took several serious looks at it during the extended alpha/beta periods. I'm ashamed to count myself in this group as well.

Tcl/Tk 8.5 definitely feels like a transitional release; it moves a lot of things forward, but it's not polished. With how long it took to get out, that's probably a good thing, or we'd never have seen it. The trick now is moving much faster towards the polished version (8.6 presumably); my understanding is that there is fairly great motivation in parts of the community to do this.

On the Tcl front, things are in really good shape. The one main thing that got cut because of not enough experience with it is the core object system. Getting that up to snuff and included in 8.6 is necessary of course. The other thing that will probably take some polishing is the new module/repository features, again because only now will people really start to bang on it.

Tk has further to go; again, this is not to diminish the great leaps forward in 8.5, both in the new widget set but also in improvements, optimizations and bug fixes (this is particularly noticeable on the Mac). As I said, everything is there now in the core needed to build a decent modern GUI, but it's still not easy or obvious. You still need to know what you're doing. The obvious polishing will occur in the new widget sets as more people now bang on it, and uncover bugs and omissions.

The bigger thing though is that the "transition" from classic-Tk to modern-Tk (new widget set) is only partially complete, and therefore inconsistent, and will be very confusing for the newcomer. The widget demo, while improved, is a mix of new and old (and some embarrassingly old). Again, no criticism intended for the core people, as it should be people like me who help bring those sorts of pieces up to date.

Being forced to make a choice (a tk::button or a ttk::button?) is still prevalent, and it's important we jump past that as soon as possible. There should be no choice needed... you use the new one. Oh yeah, and for the really advanced people, if you need to do something particularly funky, just ask and we'll let you know about this other uber-flexible 'classic' widget set that is available behind the scenes.

My fear, as with all things Tcl/Tk, is that there will be a vocal community of "no, it's important that people should know about both and choose, because choice is good" which will diminish the need to push forward to having the main official widget set which is Tk (currently Ttk!).

That of course brings up the other issue, to do with naming. Themed Tk (which started out as Tile) was originally an add-on, so when it was incorporated into the mainline, it was added as its own namespace "ttk", while classic Tk was placed in a "tk" namespace, as well as imported into the global namespace. Fine for now perhaps, but move forward into the future where we presumably want the new widget set to dominate for app developers.

Do you tell users of "Tcl/Tk" to not use the namesake "tk", but instead use "ttk"?. Why is it called "Tcl/Tk" then? That seems to be setting everyone up for confusion (choice is bad!). While there are some backwards compatibility issues to think about of course, how that transition is to work long term I'm not sure about. (Having said that, I'm sure it's been discussed, and I was either unaware or more likely forgot about it).

If the idea is long term the idea is to move to "Tcl/Ttk" instead, that could work. Given the shitty reputation of Tk, it also opens up the opportunity of rebranding it with a completely different name, completely unrelated to Tk. Imagine people using things from an entirely new "gui:" namespace (not that generic of course), so that everything that is in there is what we want to be in there and we want people to use, not because of backwards compatibility. The goal then becomes obvious, to move all the "highly recommended" standard official stuff into that namespace, with the behind-the-scenes remainder sitting in "tk:" and "ttk:". A lot of work to do that, but so much of it is also documentation and demos that don't require core-level rocket scientists.

In any case, I think the really hard work, the first 80%, has been done and done well. Now it's only the other 80% left. But with the hard parts done, there's going to be a lot more interest and energy in moving things forward. This is especially true among the Python, Ruby etc. folks who will now be looking to incorporate Ttk into their official GUI bindings. I think, if some of the historical inclinations within the user community can be overcome, things are actually in a really good position right now.

Comments

[G h]

LOL, "post 1990's." Only twenty years behind now.

[jerry]

Tcl sucks, it's just way better than bash/perl and everything else. Sort of like Democracy that way.

Does the new Tcl support threads? From the changes page at the wiki, it doesn't seem like it.

I learned tcl using AOLServer's implementation of a multi-threaded Tcl. Boy was there an awful lot of win in AOLServer's implementation.

Wow apply and dicts! w00t! And I am very much looking forward to teapot. Jebus I hate CPAN, not for what it is, but for what it made possible.

But please, I want threads.

[Mark Roseman]

Jerry, threads have been available since about 8.1, and most of the pre-compiled builds like ActiveTcl these days are thread-enabled. It's largely built on the AOLServer thread code... the Tcl core guys worked closely with Jim and the others from AOLServer.

[jerry]

Thanks Mark,

I use 8.4 at work on CENTOS, where sigh, we're not allowed to recompile the system, or download the ActiveState version (and this makes sense since we are developing code for a customer's embedded machine that will have basic tcl as it came from the distribution, but no extensions.)

When will threads be distributed as the built option for various distributions, and/or threads, really? What is the equivalent to ns_thread?

[Mark Roseman]

No idea about when different distros will compile that way (it's just adding "--enable-threads" when calling "configure".

Accessing threads at the script level is available via a very common but not distributed in core extension...man page for thread command is here: http://tcl.cvs.sourceforge.net/*checkout*/tcl/thread/doc/html/thread.html

[jerry]

Thanks, I spent the morning reading up on it. My life will be simpler when it sort of just comes compiled that way, but I will be pushing to use it where I am.

[Laif]

I think that it's a valid concern that you don't want to replace tk right away, because you might break backward compatibility. I can certainly imagine that "choice" is how this might be talked about. But it's actually a valid thing. People have libraries of hundreds or thousands of scripts they've written on their computers, and to go back and rewrite all the widget sets would be a big chore.

I think you're right, in that there will be a gradual unifying of ttk and tk... in some way, or another. I've been very impressed with the direction that the tcl/tk developers have taken over the years. The language is really well designed, as compared to a few others I've tried my hand at. It's delightful, that there aren't odd rules for how you have to arrange the code. As long as you get the parameters to the commands, all is well. There certainly need to be people out there helping people learn how to use tcl/tk - and illustrating the benefits of it. Where tcl/tk folks have missed the mark, is that they seem fairly unwelcoming to people who want to learn the language. You can have the best tool in the world.... and if no one knows that the should learn about it, it's never going to get popular. And I have heard many tcl programmers say they would wish the language would gain popularity.

[eric]

Either Linux is not a high priority for the Tcl/Tk devs, or else they stopped using Linux in 2001. I'm sorry, but as good as Tcl is (my favorite scripting language by far) there is *no way* I'd consider Tk for a gui app.

I wonder if they've heard of GTK or some of the other Linux options. gnocl is a much better choice, they should integrate that into the language itself. It's just a shame that Tk apps have to look so incredibly ugly on Linux. And all because there is some unstated reason for wanting to reinvent the wheel. Open source code can be reused, so they should do so. Tk is an absolute embarrassment.

[Mark Roseman]

Laif, thanks for your comments. Would definitely be interested in hearing how the Tcl/Tk folks are unwelcoming or how they could be doing a better job. While marketing is, to say the least, not a strong suit of the community, I'd always thought of it as fairly helpful and open to people who did somehow find their way..

[Mark Roseman]

Eric, please don't hold back. I'll make sure to pass along to the core Tcl/Tk team that Linux has had new versions since 2001, and let them know about this GTK thing you mention. They don't get out much you see, so that's be exciting news to them.

[Laif]

Eric, I agree that the Linux gui seems to have been neglected. I have not tried 8.50 on Linux... but tcl developers seem to be a bit out of the loop when it comes to the 'NIXs. The thing that might make up for this, is that is trivially easy to rewrite the language, and even create your own widget sets.

[Laif]

Well, thanks Mark for your cordial welcome... Myself, I didn't have a textbook when I learned tcl/tk. I used the help manual included with the activestate distro. I also got something out of a couple web tutorials - but there aren't many of those out there right now. I think I'm unusually apt at picking up on these kinds of things. I had to learn lots of new vocabulary to be able to understand the tcl/tk manual. Most folks would find it tough going.

Now, what I have seen in the tcl irc room at freenode north america, is that there's a certain group of arrogant folks who are allowed to strut their stuff, with a RTFM kind of attitude. Of course, these aren't the most apt folks with the language. The most skilled tcl programmers are quite congenial.... but they also don't take the time to translate their ideas into common english. There tends to be a linguistical barrier to entry, when a novice is reading the wiki, or chatting in the chatroom. That has to be lowered, in order for new people to have a way forward for themselves, when learning the language. There are many people with many different sets of skills. Not everyone who starts learning tcl/tk has had a college background in computer science. In fact, I look around the web, and I see that most people out there who are interested in Scheme, or Ruby, or what have you, start as hobbyists. So we have to appraise that social situation properly, when we write about tcl/tk. We ought to think of the target audience as a bit broader than we currently see it as, I think.

Indeed, one of the reasons tcl/tk development has been a bit slow, as compared to other languages, is that it doesn't have a large user base to draw on. If it had more people interested in it, things would be a lot faster. I imagine the concern Eric has, about the Linux gui would be addressed very quickly. And on microsoft boxes, the core tk "button" command would have used xp themed buttons years ago.

I could also relate my personal experience.

I tried to add a couple things to the wiki. My vision would be, to try to encourage people to create a much more easy to read wiki - and that's the tenor in which I wrote my little additions. However, I got a cool reception, and it seems as if there's a consensus that they want an arcanely written wiki. There needs to be a place for conversation between programmers - but a wiki, in my opinion, should be written with the reader in mind, first and foremost.

What made me decide once and for all that I wouldn't contribute to the wiki anymore, is I stumbled upon a moment of conversation in the irc chatroom, where the folks were irrationally livid about someone else who has a similar writing style as me, and who's intentions in respect to the wiki, they had misinterpreted.

And I think my experience is not unique. There might be many people who would love to contribute their skills, who feel rebuffed.

[Mark Roseman]

Hi Laif, thanks very much for sharing your experiences. I don't use the chat room that much personally, but some of my experiences there would be not inconsistent with yours... sometimes much less helpful than for example the Tcl newsgroup. There's also no doubt in my mind that there are significant barriers for contributing to the Tcl/Tk core, not deliberate by any means, but in terms of the prerequisite knowledge and sometimes lengthy process that is needed to submit 'acceptable' contributions. No question this can be a turnoff, and is such precisely for the types of contributions most needed.

[Laif]

Hmmm... you seem to have missed my point, Mark. Do you see that I agree with you, wholeheartedly? Elitists have to make the core. For the language to be good for people to use... skilled and wise people have to be those who are at work on it. I am not at all saying that tcl/tk should become like mozilla, or linux. That would just be a mess. In answer to your question about people being more welcoming, I said that there has to be an agenda of people who would help to get newbies enthused about learning tcl/tk (or tcl/ttk?). At this moment, there's a barrier to people who are interested; people don't know about tcl/tk - and even if they recognize it's merits, it's difficult if not impossible for most folks to learn the language without formal training. There's simply no way forward for would-be tcl/tk enthusiasts.

Now, to address your concern about the sanctity of the core, I would answer, that once tcl/tk has become more popular - more people will develop the skills to develop libraries....and once these folks are vetted, they might be allowed to work on the core. If there is a greater number of people who are around the project all the time, it means that there will likewise be more skilled people around to help out where needed.

Why are people so disillusioned with tcl/tk? Even some of the commenters on this thread voice this sentiment. Because they don't know the value of tcl/tk. They don't know how easy it is to use. They don't know how much functionality there is. They don't know how flexible it is. We could change those opinions. But it'll take more than just programmers. It will take writers, it will take people who are skilled with graphic design... it'll take skilled teachers. Learning a new computer language is a big investment of time and energy. And if people don't believe that it's worth it, they simply won't make the effort.

BTW... I'd better let you get on with the christmas festivities... I wouldn't want to keep you glued to your blog.

[Andres]

Tcl/Tk in Linux has come a long a way thanks to 8.5. For an example of a gui app that doesn't look ugly you can check: http://personal1.iddeo.es/andresgarci/getleft/english/snaps.html Those snaps are taking using the TileQt theme, thanks to which Tk uses Qt widgets.

[neuronstorm]

I like tcl - but I'm frustrated with the patchy support for BSD platforms.
Every now and then it just doesn't compile without hackery for example. The 8.5.0 threaded version is completely broken on FreeBSD.. whereas alpha & beta 8.5 versions worked fine.

[Brian]

Hi Mark,
Very insightful comments, thanks!

I think what is holding Tcl/Tk back is the "appearance" of lack of support and direction. Not sure if the "design by committee" model is working for Tcl/Tk.
Python has Guido, Perl has Larry, Linux has Linus, etc. Maybe we need a benevolent dictator? Not sure.

What IS the gameplan for 8.6?
There are some GREAT TIPs and ideas out there that are REALLY needed.
For example:
- TIP#308 - TDBC.
- Some kind of printing support is also desperately needed.
- Continued command consolidation (like "chan" in 8.5) would help to "clean" up the commands for consistency.
- It would be nice to pass arrays to procs.
- Completion of Ttk. (a seperate Ttk extension without the legacy Tk baggage would be nice)
- I think the Tcl/Tk plugin could REALLY help Tcl/Tk take off as you could develop in Tcl/Tk on both the server AND client side, but it needs a developer/sponsor, etc.

Tcl/Tk has some really great and unique things going for it that attracted me to it and it has tons of potential, if we could just get others to "see the light".

Maybe someone could talk Ousterhout to come back and lead Tcl/Tk to 9.0 ... ??? ;-) ;-)

Thanks Mark!
Brian