Tkinter vs. wxPython (was: Which GUI?)

[Guido van Rossum]

"Fredrik Lundh" <effbot at telia.com> writes:
> from deep inside gerrit's head.  he's completely lost it.
> better ignore him, or this thread will go on forever.

Note that Fredrik is the author of a large body of Tkinter
documentation (too bad he is such a perfectionist that someone else
beat him to publishing the first Tkinter book :-).  His company about
to launch a Tkinter-based product, so his fierce defense of Tkinter
can be explained in various ways.

I don't care much for Gerrit's attacks on Tkinter, but the reason this
thread keeps going on is that there is indeed a grain of truth.

Limiting the debate for now to Tkinter vs. wxPython, I see arguments
on both sides.


Arguments for Tkinter:

- It is well-established; the Tcl/Tk code base is very solid.

- It has a superior text editing widget,  supporting multiple fonts,
colors, embedded widgets, marking of arbitrary overlapping ranges with
arbitrary marks, and an arbitrary number of text pointers.

- It has a superior canvas widget, which supports an object-oriented
drawing model directly; it even draws splines!

- It has very smooth screen display through double-buffering.

- There's a book on Tkinter and several on Tk itself.


Arguments against Tkinter:

- It has poor printing support (PostScript only, and no standard print
dialogs).

- It lacks many common widget types, like notepads (although Pmw
compensates somewhat; but Pmw itself is not so easy to use).

- Adding scroll bars requires jumping through a few hoops.

- Its look and feel is far from native.

- The Mac support is basically broken.  This *may* be fixable easily
enough, but until someone actually submmits the patches, it's broken.

- It's relatively slow; probably due to the double buffering and the
levels of X11 emulation that it goes through, not to mention the Tcl
interpreter that has to pass all commands in text form to the Tk
library.

- It doesn't let you handle your own paint events; you have to use the
canvas widget.  Occasionally (as when drawing animations or large
bitmaps) that's annoying and slow, because you have to create and
destroy tons of small objects.


Arguments for wxPython:

- Very complete widget set.

- Faster screen update than Tkinter.

- Very good native look on Windows.

- You can handle your own paint events if you want to.

- Native print support.


Arguments against it (from very limited exposure):

- It's a relatively new kid on the block (what's currently in use is
unrelated to the wxPython that was being discussed at the GUI bakeoff
4 years ago); it can crash and burn.

- Because it's implemented using SWIG, it is potentially less robust
in the face of buggy user code; it's possible to do things that simply
hang or crash the program rather than causing a traceback.  This is
very rare in Tkinter.

- Much more simple-minded text widget (but Scintilla is coming?).

- No Canvas widget -- you must handle your own paint events, whether
you care or not.

- wxWindows is bulkier than Tcl/Tk; this translates into noticeably
slower startup times.

- Are there any books out yet?  (The wxPython documentation contains
lots of remarks of the form "the wxPython interface provides the
following two APIs instead of this single one..." so I don't buy
Gerrit's argument that you don't need separate docs.)


Personal experience:

I recently wrote a simple GUI (for a Unit testing framework) in
TKinter.  Then I rewrote the same thing in wxPython -- my first
wxPython program.  I was learning wxPython from the manual as I went
along.  I guess that this disadvantage (that I had to learn wxPython)
sort of canceled the advantage of having coded a version already.

The wxPython version is actually shorter than the Tkinter version!
(Approx. 250 vs. 350 lines of code.)  It is also much faster -- the
Tkinter version is fast enough, but the wxPython version is clearly
faster (except in startup, where Tkinter wins easily).  It looks a bit
uglier, probably because I haven't figured out all the details of
automatic widget lay-out control yet; but it looks more native.)

Naturally, I went back to the Tkinter code to see what was wrong --
but there isn't anything wrong with it.  It's just that some idioms
are a bit more verbose when using (bare) Tkinter.  For example, in
wxPython the scroll bars on the text and list widgets appear
automatically; in Tkinter I had to write a helper class and two
(trivial) subclasses.

All this doesn't mean that I'm going to rewrite IDLE in wxPython (IDLE
uses the Tkinter text widget in ways that I wouldn't know how to do in
wxPython yet), but wxPython can certainly make sense in some contexts.

I've always said, with chairman Mao, "let 1000 flowers bloom" -- there
aren't quire 1000 different GUI toolkits, so there's still room for a
few more.  In the mean time, it's likely that the big three will be
Tkinter, wxPython and gtk.  (I haven't really used gtk yet -- for now
it sounds too Linux-centric even though it has a Windows port).


Disclaimer: I've only spent maybe two afternoons with wxPython.  I may
have overlooked some things.  Let's keep an open mind.

--Guido van Rossum (home page: http://www.python.org/~guido/)