On 20/07/11 04:12, sturlamolden wrote: > 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.
I wonder - what do you think of GTK+? I've only used Qt with C++, and I've always been highly suspicious of wx (something about the API, or the documentation… I haven't had a look at it in a long time), but I always found PyGTK quite nice. > 4. They might look bad (Tkinter, Swing with Jython). Oh well. Really, while Swing and Tkinter are particularly bad as they draw their own widgets (instead of using a native toolkit), if you want your GUI to look good, you'll need to write a separate GUI for each platform that follows each platform's UI conventions. > 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.) Aye, existing GUI toolkits are mature. They work. They do the job. > 5. No particular GUI thread synchronization is needed -- Python has a > GIL. That's where you're wrong: the GIL is not a feature of Python. It is an unfortunate implementation detail of current versions of CPython. (and PyPy, apparently) > 6. Expose the event loop to Python. You can tap into the Gtk/GLib event loop. Don't other toolkits allow you to write your own loop, using some kind of process_events() function to take care of the GUI? > 7. Preferably BSD-style license, not even LGPL. Umm? > 8. Written for Python in Python -- not bindings for a C++ or tcl > toolkit. HOLD ON a second: > 4. They might look bad (Tkinter, Swing with Jython). > [...] , if based on "native" widgets: What do you propose? We know what happens when you write a fresh GUI toolkit: Swing and Tkinter show us. The only reasonable option to create a toolkit that actually looks good is to base it on the "usual" GUI libraries. > The Eclipse SWT library does some of this for Java does some of this, > though it also has flaws (e.g. manual memory management). A Python GUI > toolkit could be partially based on the SWT code. Okay, I haven't used SWT yet: manual memory management? Java is GC! It is perfectly reasonable to be required to manually call some sort of destroy() method to tell the toolkit what you no longer want the user to see: firstly, you have the display a reference to your window, in a manner of speaking, by showing it. Secondly, in a GC environment like a JVM or the CLI, it could take a moment. Was that what you meant? > Is it worth the hassle to start a new GUI toolkit project? No. > Or should modern deskop apps be written with something completely > different, such as HTML5? NO!! Don't be silly. Even using a crappy windowing toolkit is a lot simpler than doing the HTML/JavaScript/HTTP/etc dance. -- http://mail.python.org/mailman/listinfo/python-list