So, you're chugging along but don't see the light at the end of the tunnel. Are you supposed to keep chugging (don't quit!) or "be very quick to change"? Hm.
I think the one I've heard goes, the artist is imagining the sculpture beneath that lump of marble, and they explain the actual creation of it as just removing everything else that's not the sculpture.
The interview by chromatic was quite informative. Unfortunately, they say that they're forced to repeatedly reinitialize the perl interpreter with every request. This would seem to defeat the purpose of having a persistent perl, no?
It was the safe and easy install for shared hosting providers plus the easy deployment for web devs.
Really, it's a simple recipe. I'm still wondering why Perl/Python/Ruby/$fave_lang doesn't just mix together the same ingredients and do the same thing.
The rule I try to follow is to keep things as simple as you can. So, the levels of complexity for writing an app might look like this:
Level 1: command line program. Usable for yourself and others who know their way around the shell. Great for simple tools.
Level 2: Desktop GUI. More complicated, but necessary when you have non-technical users.
Level 3: Webapp with simple browser interface. When you need a GUI and need to allow access to many users all at once (possibly access to the same instance of the app). Drawbacks are that it's slow (much slower than a regular desktop GUI app) and relatively clunky. Also, you need a webserver to run it on, and the setup time that goes along with that. Also keyboard commands probably won't work and so there will be a lot of mousing around for the user.
Level 4: Webapp with some kind of Ajaxy or Javascripty client side. So, you need this even higher level of complexity when you have non-technical users who demand a prettier interface but the app also needs to be usable by lots of people on the net at once. Drawbacks are the same as with a regular webapp but also include a much more complex design, more maintenance, and more testing with different browsers.
The rule is, you don't go up the complexity ladder if you don't have to.
Unfortunately, I don't think I have the chops, nor the time right now. (But, fortunately, it may not even be necessary... see below.)
"Other than doing your own, I think the most sensible choice is wxWidgets, which, from my point of view, only has one big problem: the API"
That's a biggie. :) In fact, I'd go so far to say that if the API in unpalatable, then you should keep looking. Otherwise you'll end up just procrastinating every time you've got to deal with GUI code.
Thanks to posts in this thread (thanks Baltar!) I'm taking a much closer look at the most recent release of Tk (8.5). Given recent developments, it doesn't seem to be as "vestigial" as I'd thought. And the fact that it's implemented in Tcl instead of C may actually be a hidden benefit. And really, app developers never even need to be aware of the Tcl'ing going on under the covers. :)
IIRC, FLTK had their 2.0 version in the works a long time ago ... and it just kept being in the works. They just never left their 1.x series. Was their redesign doomed to never replace 1.x?
Looking at that list of Tk highlights, I'm getting the impression that various screenshots and wiki docs on the net are a tad out of date. It would seem that Tile has already been included. Tk 8.5 is looking quite good.
Looking at the Tile screenshots for Unix, I don't see any that are antialiased (like the rest of my desktop), though "Revitalized" doesn't look bad at all.
(Incidentally, Tile doesn't seem very active. It's last News page update is from 2006.)
I think you're right about the "marketing" for Tk. The three things that keep people away from Tk (IMO) are probably:
1. the notion that they'll have to install or use Tcl,
2. the extra work of having to install various plug-ins/theme-engines/whatever to get a more modern-looking GUI, and
3. the revulsion at seeing non-antialiased fonts in GUI widgets.
If someone were to come along and bundle up Tcl/Tk with Tile and make the whole thing dead-easy to install and start using, I think that would be a major step forward for Tk. (Hm. Looks like it may have been proposed to do that back in 2005: http://www.tcl.tk/cgi-bin/tct/tip/248 . What ever happened to that?)
Could you explain why? Last time I used Java (years ago), Swing was supposedly replacing AWT. Swing seemed very large (certainly, judging by the page-count of all the Swing books on bookstore shelves), and required a lot of subclassing to use.
When I tried it out, it was slow, to be sure, but it was also relatively easy to use. The layout managers worked well for my simple apps. I also liked the "Metal" theme, though others complained that Metal was unreservedly ugly.