----- Original Message -----
From: "Guido van Rossum" <[hidden email]>
Sent: Wednesday, February 23, 2000 7:59 PM
Subject: Tkinter vs. wxPython (was: Which GUI?)
> "Fredrik Lundh" <[hidden email]> 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
> - 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
> - 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/)
Re: [wxPython] Fw: Tkinter vs. wxPython (was: Which GUI?)
Robin Dunn wrote:
> Hi All, I thought you might be interested in these comments from Guido Van
> Rossum about wxPython.
> > [Fredrik's] company about to launch a Tkinter-based product, so
> > his fierce defense of Tkinter can be explained in various ways.