[Python-Dev] What to choose to replace Tkinter?
Tue, 24 Oct 2000 11:43:26 -0400
On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote:
>It's certainly true that the lack of a consistent look and feel for
>Linux apps has been somewhat of a problem historically. However, with
>the emergence of Gnome, it seems that there is finally some
>convergence. (Althought people in the KDE/Qt camp will certainly not
Careful... while people may try to port GTk+ to Windows, porting GNOME
is a different kettle of wax, because GNOME needs GTk+ but also
entails gnome-libs and gnome-vfs and Bonobo and esound and lots of
other things, which provide services such as object embedding that
wouldn't be required -- or would be very different -- on Windows. I
don't know if anyone is trying to tease apart GNOME into a
Windows-suitable subset; it seems like it would be a difficult task.
Qt is at least a toolkit that aims at cross-platform portability,
though there again, the KDE environment built on top of it is not
going to be portable to anything that isn't Unix. Both the Qt and
GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only
real possibilities. This is why, every time this debate comes up, we
end up sticking with Tk; it may suck, but all the other systems don't
Maybe the best approach is to follow /F's lead with Tkinter3000, and
reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that
*is* what Tkinter3000 is, right?) What's the problem we're trying to solve here?
* Is it that the problem that the Tkinter module is a bad API for
* Or is it that the Tk implementation is slow or bulky?
* Or do we just dislike having to require Tcl as well as Tk?
Can someone articulate why Tk should be replaced?