Themeing is not an excuse for ugliness, especially if no available themes look presentable. Yes, in theory, it could be awesome, but in practice, it is not.
Also, his examples really don't give enough context to show /why/ Tk themes are so bad.
Of the 5 themes he shows, only the 'windows XP' styled one even looks remotely 'ok'. The rest make AWT-era java look pretty - Swing isn't perfect (certainly on the 'feel' portion of L&F), but it's a huge improvement over AWT.
Still, Swing does prove a point, you CAN make an ugly UI more bearable by using themes alone, it doesn't make it an example of a beautiful UI, but it makes it bearable.
Pitiful excuse of an article no depth, no proper examples and to top it all bad rendering on FF. Icing on the cake - ad infested top,bottom and the sides.
Also, doesn't really explain how the toolkit itself helps the so called "GUI intelligence". UI design concepts such as not graying out things are not tk's invention, neither does tk enforce it.
Here's my take on the matter, which I know quite well:
* The guys in charge of Tcl/Tk, in about 2000, completely missed out on seeing that the future of Linux UI's was Gnome and KDE, and basically did not touch the Unix Tk look and feel until Tk 8.5. This was a major mistake. It would have actually been possible to make Tk look at least a little bit nicer on Linux without even touching the C code, but this was not done.
* However, Tk looks decent on other platforms, and these days looks decent on Linux too.
* Tk also gained a bad reputation because it made it so easy for just about anyone to throw together a GUI. Very often, 'anyone' did, with no prior training or knowledge of how to do a proper GUI, and the results have given the toolkit a bad name where it's not really deserved.
* Where there is some blame to go around is the lack of a culture of creating good GUI's. Brent Welch's otherwise excellent book, for instance, contains next to nothing about how to make a good looking, effective GUI, although it has chapters on how to use all the different widgets.
At this point, Tcl and Tk have themselves something of a marketing problem, because despite some very real and positive recent progress, and lots of nice features, everyone "knows" that they are so 1999. If nothing else, Tcl and Tk have been a fascinating study in how to market good technology badly; and by marketing I don't just mean 'selling/advertising' but gathering user requirements, keeping up with market trends, and so on. That's not to say they don't have some problems, but they aren't insuperable or worse than problems other systems have.
In any case, if you need to do an cross-platform GUI, or a quick GUI on any platform, Tcl and Tk are still a very valid choice, depending on your requirements.
"* The guys in charge of Tcl/Tk, in about 2000, completely missed out on seeing that the future of Linux UI's was Gnome and KDE, and basically did not touch the Unix Tk look and feel until Tk 8.5. This was a major mistake. "
You're totally right, but also the fonts in particular were terrible blocky messes on Linux (and may well still be, I don't have any Tk apps anymore).
I like the look of the older X toolkits. I am getting kind of tired of the modern widgets with "pretty" gradients and whatnot, and the old stuff has a nice minimalistic look to it. I compiled my Emacs without gtk+ support, and I don't regret it. I think gitk looks nice, too.
Anyway, it kind of reminds me of an era where people wanted computers to solve their problems, not solve their problems AND be some sort of fashion statement, like they are today.
I half agree. I think a minimialist toolkit would be nice, but I think tk is beyond minimalist into the austere. Also, I think that both are fashion statements -- even if the statement is "I choose not to participate".
This is what I mean by 'marketing problem': here we have an article describing how Tk can be themed, that links to a page showing more of same ( http://wiki.tcl.tk/24094 ) and it's 'austere' ? I think the idea of "Tk as old and ugly" is so ingrained that it will be very difficult to root out:-/
ctrl-mouse-left or whatever it is will still pull up a gtk menu, which looks a bit nicer. Also, it's possible, via various routes, to get file dialogs that are gtk.
I get rid of the tool bar and scroll bar too, but do leave the menu bar, as once in a while it's nice for fishing around for things I don't use often. Basically though, I just want as much screen real estate for code as possible.
> [...] but do leave the menu bar, as once in a while it's nice for fishing around for things I don't use often. Basically though, I just want as much screen real estate for code as possible.
depending on what your value for "once in a while" is, you might want to further optimize for screen real estate and just toggle the menu bar on and off when (seldomly) needed:
M-x menu-bar-mode
That's how I do it - and XMonad resizes the window automatically for me so that I never lose space and the Emacs window always fits on the screen.
Thanks for the explanation of the difference between Emacs with/without Gtk+ support.
Does anybody know how to change that "Tk" in the upper left corner? I find it garish, and a distraction from the content.
Using matplotlib for Python 2.5 on XP. I don't think there's any way to get the window handle to send it a WM_SETICON and besides, it would be best to use a native Tk call.
1. I think buttons with relief are easier to use, but other than that I am always surprised at how worked up people get about theming (but then I prefer a terminal based emacs...).
2. Tcl/Tk has some GREAT ideas that are not implemented anywhere else: the built-in event handler, trivial to write callbacks, and the everything is a string philosophy (which is strangely like a self-evaling lisp approach)
3. Tcl/Tk had some really bad luck. This weekend at opensqlcamp, someone asked Selena Deckleman why PostgreSQL has not had a tenth the market share as MySQL. She said (paraphrasing): in 1999 a lot of the core devs thought the internet was just a fad -- whoops... Same mistakes maybe happened with Tcl/Tk -- it was there just a little too early.
4. Tcl/Tk demands C to be a really full platform, and C is scary to a lot of the new breed of scripters.
Good points, but I'm not sure about the last one. There are plenty of people who use pretty much just Tcl and don't dive into C. This even surprised Ousterhout when he was still involved with things; he thought of it as a glue language when he first created it (in the late 80ies).
I find it amusing that the topic is good-looking graphics and the game in the screenshot looks butt-ugly, even for a lo-fi game.
"Extending TK to direction of breath-taking animations" is not a trivial task. Well-designed animation subsystem that combines flexibility, ease of use and performance is actually rare beast. Even iPhone/Mac OS X CoreAnimation API is not that trivial to use for quick flexible prototyping.
"Brick" engine that the author mentions seem to provide a separate domain-specific language (motion control programs) for controlling animations. Although this can be good idea, it really makes harder to combine animations with each other and other time-related tasks (playing sounds etc).
Out of the box, Tk still looks like it's ten years old. None of those "good looking" applications really fit in with the host operating system's theme either; they sort of fall into the uncanny valley of GUIs where they don't look like they're using an intentionally stylized custom theme, but they don't look native either.
It's not just the theme that makes Tk seem like an antique; there are many commonly used widgets missing also. For example, I had difficulty making an editable listbox. I googled for a while and while other people had tried to implement it, most of the implementations were glitchy and didn't work the way you'd expect them to. Given the state of Tk right now, it can be easier to just whip up a GUI in Qt or GTK+.
On the plus side, Tk does have excellent documentation.
27 comments
[ 3.6 ms ] story [ 98.7 ms ] threadSame deal in Firefox, the big image totally breaks it.
Also, his examples really don't give enough context to show /why/ Tk themes are so bad.
Still, Swing does prove a point, you CAN make an ugly UI more bearable by using themes alone, it doesn't make it an example of a beautiful UI, but it makes it bearable.
* The guys in charge of Tcl/Tk, in about 2000, completely missed out on seeing that the future of Linux UI's was Gnome and KDE, and basically did not touch the Unix Tk look and feel until Tk 8.5. This was a major mistake. It would have actually been possible to make Tk look at least a little bit nicer on Linux without even touching the C code, but this was not done.
* However, Tk looks decent on other platforms, and these days looks decent on Linux too.
* Tk also gained a bad reputation because it made it so easy for just about anyone to throw together a GUI. Very often, 'anyone' did, with no prior training or knowledge of how to do a proper GUI, and the results have given the toolkit a bad name where it's not really deserved.
* Where there is some blame to go around is the lack of a culture of creating good GUI's. Brent Welch's otherwise excellent book, for instance, contains next to nothing about how to make a good looking, effective GUI, although it has chapters on how to use all the different widgets.
At this point, Tcl and Tk have themselves something of a marketing problem, because despite some very real and positive recent progress, and lots of nice features, everyone "knows" that they are so 1999. If nothing else, Tcl and Tk have been a fascinating study in how to market good technology badly; and by marketing I don't just mean 'selling/advertising' but gathering user requirements, keeping up with market trends, and so on. That's not to say they don't have some problems, but they aren't insuperable or worse than problems other systems have.
In any case, if you need to do an cross-platform GUI, or a quick GUI on any platform, Tcl and Tk are still a very valid choice, depending on your requirements.
You're totally right, but also the fonts in particular were terrible blocky messes on Linux (and may well still be, I don't have any Tk apps anymore).
Anyway, it kind of reminds me of an era where people wanted computers to solve their problems, not solve their problems AND be some sort of fashion statement, like they are today.
I guess with these three lines in my .emacs
this wouldn't make much of a difference for me? (honest question)I get rid of the tool bar and scroll bar too, but do leave the menu bar, as once in a while it's nice for fishing around for things I don't use often. Basically though, I just want as much screen real estate for code as possible.
depending on what your value for "once in a while" is, you might want to further optimize for screen real estate and just toggle the menu bar on and off when (seldomly) needed:
That's how I do it - and XMonad resizes the window automatically for me so that I never lose space and the Emacs window always fits on the screen.Thanks for the explanation of the difference between Emacs with/without Gtk+ support.
I went ahead and published that here, in case anyone wants to track it:
http://journal.dedasys.com/2009/11/16/emacs-fiddling-show-th...
Using matplotlib for Python 2.5 on XP. I don't think there's any way to get the window handle to send it a WM_SETICON and besides, it would be best to use a native Tk call.
http://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm#M36
1. I think buttons with relief are easier to use, but other than that I am always surprised at how worked up people get about theming (but then I prefer a terminal based emacs...).
2. Tcl/Tk has some GREAT ideas that are not implemented anywhere else: the built-in event handler, trivial to write callbacks, and the everything is a string philosophy (which is strangely like a self-evaling lisp approach)
3. Tcl/Tk had some really bad luck. This weekend at opensqlcamp, someone asked Selena Deckleman why PostgreSQL has not had a tenth the market share as MySQL. She said (paraphrasing): in 1999 a lot of the core devs thought the internet was just a fad -- whoops... Same mistakes maybe happened with Tcl/Tk -- it was there just a little too early.
4. Tcl/Tk demands C to be a really full platform, and C is scary to a lot of the new breed of scripters.
"Extending TK to direction of breath-taking animations" is not a trivial task. Well-designed animation subsystem that combines flexibility, ease of use and performance is actually rare beast. Even iPhone/Mac OS X CoreAnimation API is not that trivial to use for quick flexible prototyping.
"Brick" engine that the author mentions seem to provide a separate domain-specific language (motion control programs) for controlling animations. Although this can be good idea, it really makes harder to combine animations with each other and other time-related tasks (playing sounds etc).
It's not just the theme that makes Tk seem like an antique; there are many commonly used widgets missing also. For example, I had difficulty making an editable listbox. I googled for a while and while other people had tried to implement it, most of the implementations were glitchy and didn't work the way you'd expect them to. Given the state of Tk right now, it can be easier to just whip up a GUI in Qt or GTK+.
On the plus side, Tk does have excellent documentation.