Re: I am fed up with Python GUI toolkits...

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.


.

Relevant Pages