Tkinter or wxpython?

[Cameron Laird]

In article <7x7io8r6na.fsf at ruckus.brouhaha.com>,
Paul Rubin  <http://phr.cx@NOSPAM.invalid> wrote:
			.
			.
			.
>I should also add: there is also the possibility of running a Python
>program with an embedded http server on the same desktop as the
>browser, using the browser purely as a gui, but with the Python
>program having complete access to the file system and so forth.  This
>could be seen as combining the disadvantages of both the remote web
>server approach (i.e. gui elements constrained by the browser) and the
>all-desktop approach (deployment issues).  However, a lot of the time
>it's still just plain easier to do.  Whenever I've written a desktop
>gui app I've always just been shocked at how much time goes into
>making the gui look decent and do the right stuff, even though none of
>mine have been even slightly slick (they've all been for industrial
>applications).  When I do a web gui, it's been just a matter of
>tossing some html into a file or into some print statements, viewing
>it in a browser, and tweaking it a little as needed.  Maybe that's
>mostly a matter of the lousy state of gui toolkits, and we actually
>need a toolkit that's more like an embedded browser.  But we don't
>have that at the moment.

One key to Tkinter's longevity lurks there.  While
many whine about the antiquity of the appearance of
Tkinter's widgets, they have the virtue of sensible
defaults; more than any other toolkit, Tkinter comes
up with minimal refinements in a sensible and
consistent state.  While those with an artistic eye
assure me the simplest Tkinter programs look worse
that corresponding ones built with any other toolkit,
they behave the most coherently in regards to resizing
and so on.