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. -- http://mail.python.org/mailman/listinfo/python-list
