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 23/11/03: 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.
2003-11-25 VI 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
2002-11-26 VI 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 on Nov-2006: 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.
snichols 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.
