
Tk ugly? It looks fine to me - abennett
http://www.itworld.com/development/84781/good-looking-tk
======
davidw
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.

~~~
nailer
"* 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).

------
jrockway
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.

~~~
jsrn
> I compiled my Emacs without gtk+ support

I guess with these three lines in my .emacs

    
    
        (menu-bar-mode -1)
        (tool-bar-mode -1)
        (scroll-bar-mode -1)
    

this wouldn't make much of a difference for me? (honest question)

~~~
davidw
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.

~~~
jsrn
> [...] 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.

~~~
davidw
Here's the beginnings of an idea: show it only when you move the mouse near
the top of the frame:

    
    
        (defun menu-bar-show-hide-helper ()
          (if (< (cddr (mouse-pixel-position)) 20)
    	  (menu-bar-mode 1)
    	(menu-bar-mode 0)))
    
        (defun menu-bar-show-hide ()
          (run-with-idle-timer 0.1 t 'menu-bar-show-hide-helper))
    

It's not quite right, as it seems to require some other event to happen before
it triggers.

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...](http://journal.dedasys.com/2009/11/16/emacs-fiddling-show-the-menu-bar-
when-the-mouse-is-near-the-top-of-the-frame)

------
wsprague
My thoughts about Tk:

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.

~~~
davidw
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).

------
ivenkys
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.

~~~
makmanalp
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.

------
dirtyaura
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).

------
malmckay
It's ironic that this page renders so poorly in Safari

~~~
Tyheam
Not just Safari.

Same deal in Firefox, the big image totally breaks it.

~~~
mr_dbr
It looks fine to me..

------
krakensden
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.

~~~
NikkiA
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.

------
JamesGecko
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.

------
BearOfNH
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.

~~~
davidw
Sure: wm iconphoto

<http://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm#M36>

------
maukdaddy
Yes, Tk is fugly. Only a developer would think otherwise ;)

