Python GUIs: Summary and Conclusion

Mikael Lyngvig mikael at
Mon Jun 28 19:08:40 CEST 1999


I think there is a sufficient number of replies to my original "Python
GUIs: Abondining TkInter and welcoming wxPython" post that a
conclusion can be made.  Thanks to all who replied; the replies did
exactly what I wanted - presented a lot of arguments for and against a
switch from TkInter to wxPython.

Arguments for keeping TkInter:

1. It is the most widely portable GUI.
2. It is the most flexible GUI (at least compared to wxWindows).
3. It is the most widely used GUI, documented in several books.

Arguments for promoting wxWindows:

1. It is the fastest GUI (compared to TkInter).

Two other GUIs, The FastLight Toolkit and PyKDE/Qt, were mentioned,
but they both fall outside the domain of this discussion because
they're not portable enough (one of the primary tasks of a standard
GUI must be to be available on any, or most, Python hosts). 

One other "GUI", JPI, was mentioned and dismissed because it requires
Java (so the GUI developer must know two scripting languages to make
GUIs in one of them).  However, this may be useful to some since it
gives JPython and CPython developers one GUI tool.

Really useful clues to why TkInter does not perform as well as it

(Michael P. Reilley)
But.. the argument over (these two) GUIs is not exactly a valid one.
Tkinter was written using the Tcl interface not the Tk/C API.  If
Tkinter was rewritten to use the C API, it probably wouldn't be slower
than wxPython.

Ideas to make wxPython/wxWindows more portable, which the wxPython
community may consider to implement:

(Alexander V. Voinov)
Well, let's write a sort of wxTk, and have that everywhere, where no
wxNative runs yet.

URLs for the various GUIs (excluding TkInter):

wxPython -
PyKDE/Qt -

Conclusion (my conclusion, at least...):

TkInter should continue to be the de-facto standard Python GUI.
Primarily because of its matureness, some say better design
philosophy, its portability, and its popularity.  

wxPython continues to be a good alternative, as does others, which may
be better in specific situations and to some developers.

The TkInter module(s) should be rewritten to employ the native Tk API,
instead of Tcl, which would probably eliminate all sluggishness in
client applications.

More widgets should be added to Tk(Inter).

Anyone disagree?  

Any volunteers to start work on making a native Tk C API version of
TkInter, 100 percent backwards compatible of course?

-- Mikael

More information about the Python-list mailing list