I feel your pain. The task of staying current with the vast array of technology options available, to the degree where you feel you could make an informed decision of using one over another, has reached the point of absurdity.

I am not sure I share your concern. WX is an HORRIBLE widget toolkit to learn for a python-loving programmer.

pygtk is already much more appealing. I have to try pyqt one day as so many people seem to believe QT is far nicer than GTK.

If SWT wrap into a Python friendly API, then it could be a very nice contender for the ultimate toolkit.

Tk is the way




(ok only if you are a sadist)

IMHO, the best Python GUI toolkit would apply the SWT pattern, but wouldn't use SWT as-is. The SWT pattern is to make the native GUI accessible to the high level language, then use the high level language to write an abstraction layer between applications and the GUI toolkit.

None of the current Python GUIs do it that way. The interface between applications and the toolkit is always written in a language other than Python. A GUI library with a Pythonic abstraction layer over a set of thin C extensions would have the best chance of replacing Tkinter as the built-in Python GUI.

In my experience, SWT is a primitive library, years behind Swing in functionality and with an unimportant and often undetectable margin in performance.
It has very few users (Eclipse is popular but it is only one team) and it is unlikely to improve enough to see more adoption.

Shane: why do you think that making some native GUI accessible to Python defines the unqualified "best" toolkit? Many people care about consistency and portability, which can only be obtained by abstracting away native features and doing as much as possible in the toolkit.

Guillaume: both WxWidgets and SWT are only portable on paper: they are valuable improvements over the Windows API that have been more or less adapted to other platforms, not coherently designed frameworks. (I'm not saying they are badly designed, only that the approach is "the native widget does this, let's expose it cleverly" instead of "we want this clever behaviour for our widget, maybe we can use its native counterpart to implement it".)
The current Tkinter, GTK, QT, probably FLTK are portable enough for multiplatform development; among these, only PyGTK has enough following to have a chance as a new default toolkit, but given its large baggage of libraries and the Gnome/KDE schism of Linux users I bet on an improved Tkinter using Tk without TCL: it would be compatible with the old one and faster.

Not that choice is a bad thing, but I agree with the general feelings that have been circulating about this. There has been a lot of talk and thought about Python being just a little bit too diverse. The problem, I would say, is less that there are different means to the same end (as they all have their pros and cons), but that the means are all incompatible, for the most part. anygui is a step in the right direction of unifying the means to all these ends. We might have choices, but we don't always have to make the choice and live with it forever. We need more work in that area, allowing up standard ways to use all the choices available, in a fashion that lets us not even know what we are using.

Is there a GUI-WSGI-PEP that someone could write? I barely know the names of some of the various Python gui-wrappers, but how about an uber-wrapper that just python-ifies the conversation, and farms out the calls to whatever wrapper is installed.

Lorenzo: I'm actually suggesting improved consistency and portability. I'm not sure what you misunderstood.

You can write the abstraction layer in the toolkit's native language, or you can write it in Python. It requires less work to make a consistent and portable Python abstraction layer.

Let me give a simple example: Let's say the Python GUI library has a Window class. The Window class goes through some indirections, all written in Python, to reach a thin Python wrapper around a native call such as CreateWindowEx. The application doesn't care how the library creates a window, since applications never access the thin Python wrapper directly.

None of the toolkits (AFAIK) work that way. Instead, there is usually a Window type implemented in C, and all of the abstraction is in C.

How does wax do a better job than wxpython? How does pyqt do a better job than wxpython? How does pygtk do a better job than wxpython?
They all do. WxPython is not pythonic, just an automatic wrapper over a C++ lib. You still have things like ID numbers and stuff that could have been done away with.

Shane: For me the SWT approach is trying to "make the native GUI accessible to the high level language", which is intrinsically bad for portability. The native GUI shouldn't be accessible, it should only be a stepping stone to implement a toolkit.
Your second post clarifies that you are actually advocating the right thing, i.e. making a consistent and abstract GUI toolkit, and the lesson you take from SWT is that minimizing native code and implementing as much as possible in a high level language is good.
From a technological point of view I agree completely, but in the specific case SWT failed to build a good framework (I mean a general purpose one, not Eclipse) over its thin wrapper.
Regarding Tk, Qt, GTK, FLTK, WxWidgets being complex C or C++ libraries with relatively simple optional Python wrappers, there are good reasons:
1) C/C++ programmers are still more than Python programmers, they are the main users of portable windowing frameworks.
2) Wrapping a C/C++ library to use it in Python projects is a straightforward and reusable work, embedding a Python interpreter in a C/C++ project only to use a Python library is ad hoc and cumbersome.
3) Strict compatibility between Python applications and major GUI toolkits is useful, for example to share themes.