On 7/19/2011 10:12 PM, 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!)
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.)
Greg Ewing's pygui project is still going and releasing new versions.
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.
I think you described pygui.
Is it worth the hassle to start a new GUI toolkit project?
Ask Greg what you might help with.
Or should modern deskop apps be written with something completely
different, such as HTML5?
An interesting question. I think the pyjamas project is aimed in this
direction, but the author says he will never port to Py3. (He explained
his reasons on this list when I suggested that.)
---
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
