A comment from a Nov 2003 'state of the union' report [L1 ] by Jim Gettys (a creator of X11):
In what ways is he right?
According to my dictionary, one definition of obsolete is "outmoded in design, style or construction". In that regard I'd say he is correct. Tk does seem to be outmoded in design or style, perhaps. But even that point is arguable.
In what ways is he wrong?
Another definition of obsolete is "no longer in use", which is very far from the truth
What's needed to change such a perception?
Is Tk now a niche toolkit, and if so, what is that niche?
wdb 2006-11-13: Tk is not only doubtlessly useful but also easy to install (get a Tcl, and in 99% of cases, Tk is included). For scripting languages, that matters.
Possibly there are toolkits which are nicer or easier, but that is a matter of taste. My taste of a gui is as follows: it may be nice, but it must be user-friendly.
Last year, a computer journal wrote about a program of mine: If you open it, you urgently wish to close it immediately. I was not disappointed about that, because a few lines below, the same article noted: The true quality appears in the depth when working with it (user-friendly). That's what I say is important.
davidw: Not being content with idle speculation, I decided to go to the source and ask Jim himself. He had this to say:
"I revised the document a day or two ago and classify it as moribund, rather than obsolete, the same category I put Motif in. I don't have much time to spend in debate.
My issues are:
Just because something isn't going forward, doesn't mean that tk isn't useful to people.
I also note existing widespread apps being converted from Tk to other things: e.g. the Linux configuration program."
I didn't want to stir up a debate with him, and already corrected him about Tcl's i18n features (although he's right about bidi), so please don't heckle him. He was nice enough to take the time to answer me, and gave me permission to post these comments.
Jim Gettys is an X guy, and in that space (ignoring windows and mac), Tk has just about completely fallen off the map. Most everyone uses GTK or Qt. - davidw
I used to be a Tk fan, but meanwhile I've tossed Tk for good. Using Gnocl now. I held high Tk for a long time but seeing how nice Gtk works (and what nice widgets it has -- a multi-column tree is not that easy to get with Tk and the canvas is almost copied from Tk), it gets tough. But again, Tcl with Gtk is still going strong. What a beauty, writing a complex feature-rich app in less than 1000 lines with a Gtk GUI in Tcl in a few days. Do that with Gtk in C. Err, yes. Tk has fallen off the map. And rightly so. Tk's time's over. Nothing wrong with that as long as Tcl is there.
LES: Bah! X has been utterly obsolete for 10 years or so. The *nix world only uses it for lack of a better option. As soon as a (really) good graphical environment for *nix arises, X will be thrown away so quickly we'll barely have time to back up our $HOME directories.
SS: You are right, for X there is not better option for now, but there is for Tk: Gtk, Qt, wxWidgets, and so on, so people don't use Tk just as you imagine they'll throw away X. Tk got a lot of stuff right when it appeared, but now is time to update (very hard), or to use a modern toolkit as front-end, like Tk does for win32. Note that Gtk is quite good for the purpose because it has a canvas widget. And about the idea that the only problem with Tk is the fact that it looks like Motif, I think there are more problems than that: 1) too few widgets, 2) feel in general is more row, 3) you can't use it from C directly, that turns to be you can't write bindings for other scripting languages without to open a Tcl interpreter. My feeling is that the part to take from Tk is the API, for all the rest there is already opensource code waiting to work as modern front-end without to cost hours to the Tcl comunity.
LV: While it is true that, from a C or C++ programmer's point of view, more code is being written using gtk/kde toolkits, what about from a scripting language point of view - what scripting language / alternative windowing toolkit has more code being written? Then, on top of that, add cross platform to the criteria. Is there a language and windowing toolkit which is used in more cross platform applications than some language and tk?
davidw: LV, Python has both Tkinter and wxWidgets. Tkinter is included in the Python distribution, so it's still pretty popular, but wxWindows appears to be gaining ground rapidly. Getting the native look/feel on linux, mac and windows is very attractive.
FW: IMO, practically the sole reason the casual user of Tk on X would perceive it as outdated is because it looks like Motif, which does have a stigma. There's the style part.
PWQ 2003-11-23: What ever happened to adding transparency to the core? IE when can you type:
entry .e -background {}At the time there was a large body of users that slated the lack of transparency for the reluctance of people to use Tk.
IMO the specifing and handling of options is another arcane feature.
DKF: What I don't see (with a few exceptions) are people that are using Tk for their business also coughing up some money to help pay for development of Tk. They're instead relying on the free time of people who are often rather busy with other things. They're entitled to do that, but it doesn't help secure their investment into the future. And the people who know how Tk works will continue doing other things for a large fraction of their time to help pay the bills...
Rumors of Tk's demise are greatly exaggerated...
davidw: I think what I still really like about Tk is the simplicity and elegance that pervade the Tcl way of doing things. Do the common thing quickly and easily, and then add options if you want to do something fancy. I think that's a pretty smart way of doing things, and it involves a genuinely different approach than just ugly copies of C API's... procs/functions with 12 different arguments that must be filled in.
VI 2003-11-25: I am a hardware engr who was a software engr and use Tcl extensively. In the EDA Tool world, Tcl is just catching up. Every single vendor is switching to be Tcl based, and it's vendor neutral. Both Synopsys and Cadence (arch-enemies in everything else) use Tcl as the base for everything (examples are Design Compiler from Synopsys and NC Verilog from Cadence, vsim from Mentor Graphics). Some have always been that way and some are new converts. Tcl is in my world to stay - at least for the next 10 years...
Tcl, or the Tk toolkit, or both? - davidw
VI 2002-11-26: DC (which is short for design compiler, and primetime, which is the static analysis tool both from synopsys) use only Tcl. NC verilog (which stands for native compiled verilog from cadence) uses both Tcl and Tk (as part of ncsim -gui). vsim AFAIK always used tcl and Tk.
Xilinx has started shipping Tcl as part of their ISE6.1 release, though they still seem to have a lot of java and mainwin stuff around. Tuxedo (which is now called Conformal, a logic equivalence checker) from Verplex also uses Tcl (not so sure about Tk), and I'm sure their other tools use Tcl too.
Many (if not most) hardware designers work on linux and solaris, windows just isn't capable enough of handling 3GB data gracefully. Tk fits the bill just fine. vsim is the most mature in its Tcl and Tk usage, and modelsim (which is now part of mentor graphics) have their own widgets and the look is very professional.
My employer http://www.comit.com/ uses tcl for everything from web forms to sysadmin. We also hve a suite of tools for hardware design based on Tcl and Tk. Just to prove the point that Tcl and Tk are here to stay and in my current field have a growing suite of companies adopting it and a growing user base.
Some names there might not make sense in the software world, but those are big companies I'm talking about and most EDA tools sell for tens of thousands of dollars (some for a million). So we're not talking about tiny tools here.
Jim Gettys' comments are a wake-up call for Tk. I use Tk for scripting applications for my own use: such use will never figure as "visible" application development. More important than "visible" development is whether developers still learn and use Tk for their own purposes. Unfortunately Tk is losing ground to wxWidgets and GTK in this area (at least with Python). Jim's criticisms of Tk are valid ones.
While it is true that Tk has native look-and-feel under Windows, this is true under UNIX only in a very narrow sense: the UNIX desktop has improved dramatically in the last 5 years, yet Tk still looks like a clunky Motif application. Theming, and compatibility with freedesktop.org standards [L2 ], are essential if Tk is to continue to be a first-class toolkit.
Here's some evangelism for python's wx GUI over tkinter [L3 ] (cited without prejudice ... there's quite a bit in the article)
A WxWidgets alternative
Copied from I worry about Tcl's future
LES 2006-11: I am not really an expert, but I do read and try a lot of stuff, and after 3 years using Tcl, I am still firmly convinced that Tcl is, sadly, an excessively well kept secret. If more developers took the time to shake off all prejudice and examine Tcl a little more, they would have nothing but the insecurity of working with an unpopular language to deal with. Tcl has all and a few other traits that many languages pursue and haven't managed to deliver to-date. Sadly, Tk is a different story. Tk is obsolete, no question about it. wdb Not yet seriously tried another toolkit, but this serious question: is there any tk the text widget of which is on a par to Tk's text widget? Allow me to doubt that.
RLH: Some of those issues are being addressed (I can't say if all of them are). I would like to see a vibrant wxWidgets based alternative. Python still uses Tk as its default but wxPython has the most mind share today.
DKF: Also note that Tk now (with the CVS HEAD, and so soon in the 8.5 release) also has the Ttk widgets. They look good - very very good - especially on Windows or OSX/Aqua.
RLH: Yup, and I am highly anticipating its "release".
LES: Tk has always looked good enough in Windows and OSX. But it looks awful in Linux and DKF's comment above excludes Linux from these new improvements. (note: the Ttk widgets indeed are included in Linux, it's just that the linux platform has no single look and feel so Ttk widgets won't necessarily look like your particular desktop) I find it sad because Windows and Mac are prominently proprietary software land, but it is so difficult to make closed-source software with Tcl/Tk that Win/Mac developers will use something else. Nix is the land of open source software, but Tk looks so bad in nix platforms that developers will use something else. That could be contributing to Tcl/Tk's stationary position in a sort of popularity limbo. EKB That explains some things. I use Tk as a serious development language on Windows (e.g., at http://www.ipat-s.org/ ), and so I'm surprised to hear about how it is hardly being used in *nix land. But the stuff I create is open source. LES Yes, but can you make it closed source? Many developers would rather not reveal their code (ideologies aside) and Tcl is not good at all at protecting code from inspection. EKB Yes, I see that that's the big question you raised. I use freewrap (not the most recent version), and apparently file encryption is now available with most recent freewrap. That could be one way to do it.
DKF: It would be great if we could have some better styles for Unix. But I'm terrible at graphic art; I've never had the nack for it. EKB I wonder if the thing to do in this case is to make it easy for graphic artists to make changes, rather than turn into a graphical artist onseself. For myself, what would be ideal is to not have to change my code (which Tile asks me to do), but be able to change what a "button" means, using additional formatting files that would be easy to modify. The formatting files would offer graphical artists a new canvas to work with. It's similar to the idea behind themes, but so far I have not found the benefits of Tile to make it worth the cost of switching.
Kevin Walzer: I disagree that it is difficult to make commercial software with Tcl/Tk. I'm a Mac developer exclusively, and Tcl/Tk is my primary development environment. See http://www.codebykevin.com for some screenshots. I make extensive use of Tile, tablelist, and BWidget in my apps; with these components it is very easy to create nice-looking GUI's that fit in well on the Mac. Using pure Tcl/Tk is another story...I wouldn't attempt that with commercial software. But Tile makes such questions moot. Indeed, with Tile and other appropriate extension packages, building a GUI on OS X is just as easy with Tk as it is with Apple's tools, specifically Xcode ([L4 ]) and Interface Builder ([L5 ]).
Bryan Oakley: I'm going to throw my hat into the ring and counter LES's contention that Tk looks "awful" on Linux. I'll admit I'm biased, but I don't think my app looks awful on linux. The following screenshot is from a work in progress that uses Tile 0.7.8 and tk 8.5a4. It is untweaked for linux (read: developed on windows and mac, no special code for linux) and looks pretty good out of the box: http://www.tclscripting.com/edgenotes2/screenshots_files/page1-1000-full.jpg . Admittedly it needs a tiny bit of tweaking but it's a work in progress and I have other priorities at the moment. I just don't want the Ttk widgets on Linux to get a bad rap. LES I am impressed. You're using a windows manager theme (the green decoration behind "Edgenotes 2.0") and Tk did not ignore your theme choice. That's new in Tk's history and certainly very welcome. That and xft finally included as default.
LV: What I find funny about all of this is that when I look at normal screen shots of X11 desktops, I often see a hodgepodge of styles on the apps. And if I don't see that, I see garish abominations which should never have been shown.
Where are the simple, sleek, attractive stylings? Things have been going downhill since Motif/CDE. While letting users and developers create and assign their own stylings may be more democratic, it certainly doesn't lead to better designs.
I don't think that it is possible, frankly, to create a GUI that is going to please everyone. As long as it pleases someone, that should be sufficient. The problem comes if a toolkit has insufficient capability to satisfy anyone.
For most users, if the application doesn't look like Microsoft Windows, then they are unhappy. For some of us, if it DOES look like Windows, then we are unhappy ;-)
APE: Sorry about my english (I am a french guy) but I really needed to add something to this very dark view of Tk. I am using TCL/Tk in the industry since many years and keep thinking that it is a good environnement for testing and maintenance tools ! The GUI we developped reached the desired ergonomy, look and quality with quite little effort !
RFox Dunno...this seems really strange...If I look at just about any scripting language that has GUI support they've lifted Tk and embedded it. Perl, Python...someone must think Tk is worth that effort. Why is Tk not going to be obsolete in the near future: You get a lot of bang for very little use effort. And the interfaces you make with it work. They don't have these little glitches that I'm used to seeing with 'modern' toolkits.
LV: Well, to be fair, most languages set up Tk implementations first because it is so easy. However, once their developers begin using it, the clammer for more contemporary looks begin, and eventually, they move on to GTk, KDE, or some other toolkit.
What I like about Tk, though, is something RFox mentions. In the past, at least, using Tk has been pretty simple. I don't know if the addition of the Ttk package continues that tradition or not. I've not really messed with it much. But the ability to do, in a half dozen lines, something that in other languages takes pages of code, is a feature of Tk that I've always respected.
Tk's default image support is dire. It works alright for little GIF icons though. The photo widget/subsystem doesn't scale well with large images, and lacks many needed features. Tkimg isn't a solution -- more like a problem, built on top of a poorly scaling design. It should be possible to use any image decoder/encoder and perform manipulations in Tcl, and then display those images with Tk. Unlike some other toolkits, Tk also lacks an optional shared memory transport for X11/unix systems. (BTW I wrote solutions to all of these problems with megaimage, jpegext2, pngext2, and megaimagetk, but they won't be integrated with Tk in the standard distribution.)
Tk's printing support isn't good either. I proposed having a public API for retrieving a widget/window's pixmap, or current area, so that this could be fixed, but no one followed up or even responded to my idea on tcl-core years ago.
So, while Tk isn't completely obsolete to me, it's limited out of the box -- too limited.
Bryan Oakley Personally, I think "dire" is a bit too strong with respect to Tk's image support. The vast majority of GUIs don't need to do much beyond display some toolbar buttons and very simple graphs. While Tk isn't up to the task of being the language of choice to rewrite Photoshop (or arguably even Paint.exe) it's quite sufficient for the lion's share of what most GUIs need.
As for printing... yeah, that situation continues to suck. I print maybe a couple dozen pages a year so it doesn't bother me much, but most commercial applications need to support some sort of printing model. It's a tough problem to solve in a cross-platform way. This is the one place above all others where, IMHO, it wouldn't be a bad thing for Tk to have different solutions for different platforms. I'd rather have three different non-portable solutions that no solution at all.
Since I changed jobs about six months ago, I've started programming in other scripting languages: Python and Ruby. Both of these include Tk in their standard libraries. I think as long as these other scripting languages continue to include Tk in their standard library it will stay popular. This is because most developers would prefer to not to have to download, configure, and install other third packages and modules if they don't have to. By the way, at my new company CLI apps seem to be more popular then GUI's anyway's. I think this because the CLI's can be scripted and wrapped if needed.
RLH:
While those languages do include Tk in their standard libraries they are not encouraged to be used. Python I know leans heavily towards wxPython and the wxWidgets (or whatever it is called now) toolkit.
LV: going back to the top of this page, how about a 2007 look at the strikes against Tk that originally started this page:
Does Tile really address this? That is to say, if one is using KDE, GNOME, Vista, or MacOSX, and has selected a theme for their desktop, will a Tk/Tile application automatically look like the rest of the applications?
What improvements over the 3.5 years of Tcl/Tk 8.5 development apply here?
While I recognize that Tcl and Tk provide some degree of i18n and localization, are we at full level, compared to other toolkits?
What progress has been made for the specialized languages where, I presume, output and input are not traditional left to right, top to bottom, style?
This is not a technical issue. It is, I suspect, more an issue of taking more advantage of Tcl-URL!, advertising new and updated applications.
All I can say is that I admire the power of POSIX tools. I use cygwin and MontaVista on Windows, Solaris environments and part of my toolkit for multi-platform support is Perl. Tk is the only easy to install graphical toolkit for which I can write programs that run on Windows/Cygwin, ActiveState Perl and Solaris (and in the future maybe Linux).
Scott Beasley: <Sarcasm> Wow, I guess I've made a mistake re-writing PowerBuilder and .Net Gui based apps in Tk. Why did I do that? Oh yeah.... It works, I keep forgetting.</Sarcasm> To date Tk is the best overall GUI set for TRUE cross platform usage.
WJG 2008-11-13: Its often said that Tcl/Tk offers cross platform development and, true, it does. But then, which serious scripting environment is not cross-platform? In the late 90's I became hooked onto Tcl because I wanted to program GUIs on my Linux box. In those days most things looked awful and Tk looked good. I also had access to Windows machines, Macs and SGI workstations. Nice, I could now develop wherever I liked. But, did I really need to? Back then Tk was seen as a one tool for all. And again, true, it can be. But, does it need to be?
If the argument for using Tcl is Tk, which for many it was, then why have other scripting environment taken the lead over Tcl? Tk'ers boast of the inclusion of Tkinter with other packakges, but then TkInters sits there along with many other graphic toolkits.
Its not that Tk is obsolete, Tk is old fashioned, like loons, Oxford bags or ha'penny round collars. Ask any a new comer to coding which scripting environment he should know, the chances are its Python. In the UK talking about using Tcl/Tk almost gets a giggle. Personally, I'm not interested in Python, I like Tcl way of doing things. Its simple.
Do I have a solution? Perhaps. Tcl should be promoted more, promoted separately from Tk. I don't want to cause offence, but Tk should be accepted for what it is, a loadable module. One of many useful loadable modules.
In closing, it would be interesting to take a poll of Tcl users to see whether or not they genuinely need cross-platform graphics. Is it a desirable feature, rather than a necessary feature? In terms of the future, if full cross platform applications are needed, to run on any machine, anywhere, then Tcl scripted on-line applications should be worth considering. Maybe some way of using Tcl to script new Goggle Aps. But then, is it really needed?
Long live Tcl, ta ta Tk!
Bryan Oakley 2008-11-13: if you think you don't need a cross-platform GUI toolkit, think of it as three platform-specific toolkits that happen to share the same API. If you take the time to learn a toolkit on one platform, isn't it nice to know your hard-earned knowledge will transfer if you ever find yourself working on a different platform? My Tk experience started on SunOS, then to AIX, then to Windows. I got stuck on Windows for a while, then was briefly tasked with porting a GUI to Aqua. I use a Mac at home where I do most of my tinkering. Then I got a gig working on a linux box. For the better part of a decade I was able to leverage my GUI expertise without having to learn a new toolkit.
WJG 2008-11-14: You give the reasons why I was first drawn to Tk. My experience speaking with users of other scripting languages, even though Tkinter is there, they choose something else. Ok, this is my personal experience, it may be limited. But, when people choose a scripter, they choose a 'fashionable' language, and then use whatever Graphics front end they have that is vogue for the platform they're using. My point is this, Tk is an add-on to Tcl. We should be out there saying, Tcl is good, it will work with the most popular graphics environment for your system. Ok, I use Linux 99.99% of the time, and I use Gnome. I want Gtk compliant apps. Tcl gives Tk its method of working, and that is good. It is the good features that should be promoted, not Graphics. Unlike the times when John created Tk, there are many different graphic toolkits out there, some of them, like Gtk, owe a lot to Tk. But, if Tk, is so hot, why is there now reducing interest in Tcl!
NEM: Because people often make bad engineering choices, such as choosing a GUI toolkit based on fashion and popularity?
WJG: It is a cosmetic issue. I run Suse using Gnome yet KDE is the 'default' desktop. It is a matter of choice. When Tk came along, there was little choice. Now we have lots. Years ago VHS won the war over BetaMax. A lesser system prevailed over its better rival, why? Popularity, market selection. The whole history of IT is rife with good product cast aside due to market demand. Strip Tcl/Tk of Tk, re-align it with other scripting languages and let Graphics Toolkits be a secondary issue. I know that this will upset the grumpy old men in the Tcl/Tk community but that's the way forward. Tck/Tk no longer leads the crowd, its becomming left behind and for no good reason other than appeal. Tk may be OS transferable, this is not the problem, it needs to transfer into the decision list of professional coders. If not, then Tcl/Tk will eventually become an hobbyist or enthusiasts language and, soon as that happens, few will touch it.
Years ago I worked in the TV graphics sector and when Alias-Wavefront Maya came out, it was so obvious that the GUI was created in Tk. The scripting language MEL was derived from Tcl. But then, 'other factors' lead to a Tcl type scripter becoming dropped in favour of Sophia, now changes are afoot and Python scripting is available [L6 ]. Why hasn't Tcl been reconsidered? I'm not certain but, I guess for the strongest reason of all -fashion and popularity.
There is a certain irony though, Python is named after the TV show Monty-Python, now there's something outdated, outmoded and relegated to history.
Lars H: But does any of what you've written above suggest a concrete action? With respect to "Drop Tk, promote Tcl", the trend for years has been to make Tk more of an ordinary extension (one milestone being where we started to explicitly [package require Tk] for the benefit of tclkit users), and although movement may be slow (because not so much effort is invested in it, due to lack of interest), the direction is clear: dependencies in Tk upon internal Tcl interfaces are removed, generally useful features in Tk are moved to Tcl. What more is there, in your opinion, that the Tcl community could do?
From the point of view of Tcl/Gtk advocates, it might be nice if Tk died since that would produce a small influx of former Tcl/Tk developers that wouldn't abandon Tcl, but the damange it would do to the Tcl community as a whole (making people switch to Java, Python, Ruby, or whatever) would probably far outweigh any benefit that might be drawn from attracting some Gtk afficinados.
WJG: I'm not advocating Tk developers in favour of anything, that's good carry on with it. I'd like to see more people our there who develop using scripting languages to become more aware of Tcl and look at some of its advantages.
NEM (Replying to WJG): Firstly, a lot of work has already been done to separate Tk from Tcl so that it operates as just another extension. Secondly, Tcl is a language, not a product. Its survival does not depend on being widely adopted. Popularity brings lots of disadvantages too. Personally, I've grown to quite enjoy Tcl being somewhat under the radar. Why does it matter if Maya chooses Python instead of Tcl? They're both fine languages.
WJG: Personally, I'd like Tcl to be more popular, rather than hearing the word Tcl/Tk developer, I'd like to hear Windows Developer using Tcl plus ...., Aqua developer using... and so on. As you say, the Tcl will survive, but it needs to thrive.
peterc 2008-11-17: Part of the problem in discussing Tk is that there's a difference between Tk (the widget management and display system) and Tk (the widget set). I'd actually love to see the latter bits spun off into their own package (say, TkWidgets) leaving the widget management and display system as the Tk core. To me, Tcl/Tk is Tcl, Tile and other widget sets. That Tcl/Tk produces multiplatform apps that look and feel modern and (with rare exceptions) platform native. Spinning Tk widgets off to a TkWidgets package would also trim a few hundred K from our starpack basekits too :-).
ZB 2008-11-14: it would be interesting to take a poll of Tcl users to see whether or not they genuinely need cross-platform graphics But of course (at least I need).
Is it a desirable feature Yes, it is. No doubt.
Casteele - 2016-06-24 04:29:02
It is 2016 as I write this, and I still use Tk, and see applications and utilities written with Tcl/Tk. I also still use things like DOS batch files, write some code in BASIC and Pascal, and so on. I also use Microsoft's .NET, and still use the older non-.NET compilers. I use Mono, the *ni version of .NET. I use Perl, Python, C/C++, AWK, Bash scripts, and on and on. My point is, Tk is not dead, and it probably will not die in my lifetime. Not because it's the biggest, best, "one tool to rule them all" or anything, like some people seem to want it to be, but because it does one specific job, and it does it exactly how it's supposed to do it. It does not try to be some all-encompassing, all-knowing, answer-to-everything.
And that is what I think the problem is with those who seem to think it's dead, or useless; It does not do everything they want it to do. And it shouldn't, else it'll become overly big, bloated, with millions of bytes of code just to be able to handle every possible need and use that someone can come up with. Look at how the web is evolving for an example of this; My web browser is eating away at 25% CPU and just shy of 2 GB RAM, just to browse pages like this! I often just download the text from pages and load them up in my text editor, reducing the load to under 2-3% CPU, and only a couple MB RAM, because my text editor does not try to be the answer to every possible need I may have; It only tries to be a great text editor. (And it succeeds in that, IMO!)
While it is true that there are now many more tools, such as GTK, wxWidgets, etc, I believe there will always be a place in computing for Tk. Just as I have a place and need for my toothbrush--I could replace it with a fancy high-pressure washer, like I use to wash my house or car, but why? It does the job it's meant to do without shredding my gums!
What I'd rather see here, and people focus their efforts on, is rather than try to slay and bury Tk, put that energy in to how we could improve Tk, make it more useful, do the things people keep complaining that it cannot do. Tk is just computer code, same as GTK and wxWigets, so it can be rewritten to do the same things, if people would make the effort.
.. At least until the next Mayan apocalypse truly wipes Tk out, along with everything else ..
