On Jul 19, 9:12 pm, sturlamolden <sturlamol...@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. -- http://mail.python.org/mailman/listinfo/python-list