What is wrong with them: 1. Designed for other languages, particularly C++, tcl and Java.
2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. 4. They might look bad (Tkinter, Swing with Jython). 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) How I would prefer the GUI library to be, if based on "native" widgets: 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. 5. No particular GUI thread synchronization is needed -- Python has a GIL. 6. Expose the event loop to Python. 7. Preferably BSD-style license, not even LGPL. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. The Eclipse SWT library does some of this for Java does some of this, though it also has flaws (e.g. manual memory management). A Python GUI toolkit could be partially based on the SWT code. Is it worth the hassle to start a new GUI toolkit project? Or should modern deskop apps be written with something completely different, such as HTML5? Sturla -- http://mail.python.org/mailman/listinfo/python-list
