Monday 11 July 2005 — This is nearly 18 years old. Be careful.
PySWT is a Python binding to the critically-accliaimed SWT GUI library from Eclipse. I’m torn about this. On the one hand, I like high-quality tools made available for us all to use. On the other hand, why do we need another? How does this do a better job than wxPython?
Part of the Zen of Python is “There should be one —and preferably only one— obvious way to do it.” While this needs to be taken with a grain of salt (the URL is Humor.html, after all), the libraries available for Python have strayed far from this ideal. Everywhere I look I see too many choices.
I’ve whined about this before, to what end, I don’t know. I can’t imagine the Python community will somehow consolidate to have a single GUI framework, a single web app framework, and so on. Part of the fun is the ease of getting a project off the ground, then finding a large enough audience to keep it going.
It's interesting that having just one way to do things is part of the core Python philosophy. Especially when compared with the Perl philosophy - "There's more than one way to do it".
I think though that staying current will all the ways of doing things has generally been impossible. There are for instance so many options available for the choice of database engine, programming language, etc. that rating them all on technical grounds is almost impossible. In the end, it comes down to knowing how to find a good set of opinions on the pros and cons of the different things when you need to use them.
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.
(ok only if you are a sadist)
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.
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.
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.
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.
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.
Add a comment: