I am fed up with Python GUI toolkits...

[Adam Tauno Williams]

On Tue, 2011-07-19 at 19:12 -0700, sturlamolden wrote:
> 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!)

I've no idea what this means.  I happily use pygtk.

As for "application frameworks" maybe you are referring to their having
their own event-loop, etc...  They don't have any choice.  A UI toolkit
has to have an event-loop and related pluming.

Gtk builds on top of glib; which has its own event-loop etc... This
makes perfect sense to me.

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

Widget registration / hierarchy != memory management.

> 4. They might look bad (Tkinter, Swing with Jython).

Sorry, I think Gtk apps are very nice looking.

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

PyGTK just released version 3 with GObject introspection.  etk.docking
went beta a few months ago [a pygtk docking solution].  All seems pretty
alive to me.  And the developers respond to questions.

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

Sounds like PyGtk to me.  All that other stuff and you are on your own.

Although I'd like to have data-model binding.

> 2. Do as much processing in Python as possible. No more native code
> (C, C++, Cython) than needed.

Unreasonable.

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

NEVER GOING TO HAPPEN.  UI's don't work that way.  They are inherently
hierarchical.  Just get over it.

> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable

Gtk supports multiple canvas modes.

> 5. No particular GUI thread synchronization is needed  -- Python has a
> GIL.

Wrong.

> 6. Expose the event loop to Python.

It is.

> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.

Why.  Pointless. That is just re-implementation.