I am fed up with Python GUI toolkits...

[Thomas Jollans]

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.