I am fed up with Python GUI toolkits...

[sturlamolden]

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