I am fed up with Python GUI toolkits...

rantingrick rantingrick at gmail.com
Wed Jul 20 08:52:30 EDT 2011


On Jul 19, 9:12 pm, sturlamolden <sturlamol... at yahoo.no> wrote:
> What is wrong with them:
>
> 1. Designed for other languages, particularly C++, tcl and Java.

This fact bugs me but no one is willing to put forth an effort to make
things happen. So we are stuck with what we have now.

> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython).

Users should NEVER need to explicitly destroy a dialog. However it
would (should) be easy to subclass the wxDialg and create your own
logic tied to the ok and cancel buttons. See tkSimpleDialog for old
inspiration or see my threads on tkSimpleDialog improved for modern
inspiration.

> Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.

There is nothing wrong with hierarchy. Please show examples where this
relationship fails.

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

Well you've got to get some "like minds" together. I would be willing
to participate on something more Pythonic. PyGUI looks promising.


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

PyGUI

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

Some heavy lifting must be done in these languages.

> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up.

I don't see how that "messes things up"?

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

Hopefully you want a canvas at least. I don't think i could get by
without one. Not only is a canvas good for drawing graphics via user
input but also for creating custom widgets that the GUI does not
expose.

> 6. Expose the event loop to Python.

This would be nice.

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

Agreed! Wx is nice but feels too much like writing C.

> Is it worth the hassle to start a new GUI toolkit project?

It's a huge hassle and might be much better to grow/repair some
existing API's. PyGUI is one however it's very young. Tkinter could
use some re-factoring however it will always be based on an embedded
TCL interpreter doing "magic" behind the scenes.

> Or should modern deskop apps be written with something completely
> different, such as HTML5?

F___ NO! That sort of thing needs many more years to mature. Currently
we are in the beginning phases when everybody has "their" idea of what
is perfect and nobody agrees on which is best. Plus you have many
incompatibilities between the major browsers. People like to parrot
off about how cross-platform these things are compared to GUI; and
that's true only for the same version of the same browser. You just
switch from OS incompatibility to browser incompatibility.





More information about the Python-list mailing list