![](https://secure.gravatar.com/avatar/a0f69035374239eb554cf5d7f4ef1f4f.jpg?s=120&d=mm&r=g)
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