Tkinter and wxPython

[Malcolm Tredinnick]

On Sun, Jan 23, 2000 at 05:45:47AM -0800, Timothy Grant wrote:
> OK, After just spending three weeks learning Tkinter on-the-fly, I have
> to ask this question, what advantages/disadvantages are there to each
> Tkinter and wxPython?

I'll have a stab at this and will no doubt be stomped on by greater minds
tomorrow (although most of the Greater Minds are probably all at the
conference, so I may be safe) ...

Tkinter:
+ It is truly cross-platform: The same program will run without changes on
machines with MS Windows, MacOS or any version of Unix that can run a version
of X Windows. You can also be "reasonably certain" that if Python is installed
on a platform, Tkinter will be there, too (or, if not, can be easily
obtained).
+ It is reasonably well documented and getting more so. There are already
articles around on how to "translate" Tcl/Tk man pages into Tkinter commands
and I, personally, have found some stuff on Perl/Tk to be helpful here, too.
An O'Reilly publications book on Tkinter is due out later this year.
- It is a bit slow to start up and run (since Tk is written in Tcl, which is a
fairly slow language -- at least by Python standards).
- Many people feel it looks a bit "clunky", although this seems to vary from
person to person. I don't mind it (and the amount of time I spend playing
PySol means I spend a lot of time looking at a Tkinter interface :-) ).

wxPython:
+ A bit more "feature laden" than Tkinter in some respects (this may be a "-"
in some books). More things are customisable (sort of -- see below). I believe
there are more "ready to work" gadgets in wxPython, but I haven't sat down and
counted and I don't use Tkinter much, so I probably don't know what is really
available there.
+ Although I haven't benchmarked stuff, it certainly feels faster than
Tkinter. Noticeably so when starting up a program, but also when a program
with a lot of windows is running. Tkinter tends to bog down a bit when lots of
windows need to be updated. wxPython is a step or two closer to the native
C-code (well, C++ code in this case), so this may explain it.
+ Updated regularly. Robin Dunn (Mr. wxPython) seems to fix bug reports about
two minutes before you send him the email and you can download the current CVS
version (or even a compiled snapshot thereof for Microsoft-types) as often as
you like.
+/- Not a lot of documentation (in a nutshell: read the wxWindows docs and
then you know pretty much everything about wxPython. The problem is, the docs
are like a reference manual, rather than a tutorial). However, (good point!)
the wxPython mailing list is an excellent source of help.
- Trickier to install than Tkinter. This is partly because wxWindows, the
product it is wrapping is still very much in development, so there are a
reasonable number of bugs (although I seem to have stopped being bitten by
them in the last three or months, so it is definitely getting better).
- Not included with the standard Python distribution, so if you are
distributing an application, you need to include instructions on how to
download and install wxWindows and wxPython (again, this is getting easier
every day, but it is still non-trivial).
- Not available (yet!) on Macintoshes, although Robin recently made it clear
he will be happy to fix that as soon as a Macintosh machine complete with
development software is made available to him. (wxWindows is available on
Macintoshes, so it's "only" a matter of getting the Python bindings to
compile, as far as I understand it).
- Your applications don't look and feel 100% the same on MS Windows and X
Windows platforms. This is because wxWindows does *not* aim for the lowest
common denominator across all its implementations. Rather, it supplies a
bunch of features and some of them may be no-ops on any given implementation.
The differences, however, are not major (mostly cosmetic things).
- Steeper learning curve than for Tkinter. wxWindows (and hence wxPython) is a
BIG package and can be quite intimidating if you haven't done any sort of
windows class library programming (GTK, Motif/LessTif or MFC, say) before.

Having written all that, my own personal preference is for wxPython for any
moderate sized application and Tkinter for the "quick and dirty" stuff where I
just want a window *now*. I like the look-n-feel of wxWindows applications.
Of course, I only write apps for myself, so my audience is very sympathetic
towards the programmer. :-)

Don't be too put off by the extra learning for wxPython -- you won't be able
to write the next super-app overnight, but with a bit of work (and much
reading of the example/test scripts) it is manageable.

Hopefully this is of some benefit (and not too far from reality).

Cheers,
Malcolm Tredinnick

--
For every action there is an equal and opposite criticism.