Python GUIs: Summary and Conclusion

[Michael P. Reilly]

Mikael Lyngvig <mikael at pobox.com> wrote:
: Hi,

: 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.

[Summary of arguments snipped]

: 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?

I've already rewritten _tkinter to use a new pytcl module, but the
functionality is still the same, ie. executing Tk calls from within an
interpreter.  But I'd like to see it using the TK/C API (so much for
my hard word on rewriting _tkinter *wink*).

The main issue would be to make it extensible for adding the new
widgets and other extensions (BTL, PIL, etc.).  Also, the interface
between Python and C would not be as "simple" as the existing module.
It's doable tho.

Note that using the "native" Tk API would still require linking with
the Tcl library.

I could scratch my _tkinter rewrite and work on a native solution.
(I could still publish my pytcl module.)  Any thoughts?

We already know that Python 1.6 won't be until the new year, so any
changes to Tkinter would be as a patch.

  -Arcege