[Python-Dev] What to choose to replace Tkinter?

[Andrew Kuchling]

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
support everything...

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
       GUI programming?

     * 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?

--amk