Tkinter: The good, the bad, and the ugly!

Owen Jacobson angrybaldguy at gmail.com
Fri Dec 31 03:14:44 EST 2010


On 2010-12-30 19:43:21 -0500, Gerry Reno said:

> For those that are lurking, this might provide a little background:
> 
>     http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong
> 
> 
> 
> Essentially, there is nothing "wrong" with Tcl and Tkinter.  They are
> part of a long evolutionary chain of how we got to where we are today.
> They deserve to be respected for the contributions that they have made.
> 
> The question now is whether Python needs to evolve its own GUI toolset.

My two cents, given freely: I'd rather have better integration with 
each platform's GUI libraries and desktop services than one 
cross-platform GUI library. There are so many fundamental differences 
in accepted behaviour between each of the major GUI platforms (Gnome, 
KDE, Mac OS, and Windows, at minimum; you could include Blackberry, 
iOS, and Android in here as well, if you wanted something really 
different) that being able to put the same window with the same widgets 
on all of them is of limited value.

Consider Java's Swing toolkit - a passable cross-platform GUI library, 
whether you like its API or not. Swing apps almost *never* feel as 
pleasant to use as a native application, even on modern JVMs where 
performance isn't the problem and even using the native look & feel. 
Little things like keyboard shortcut conventions, mouse button 
conventions, and menu organization guidelines don't quite mesh. Then 
there are more complex issues, like process management, library 
packaging, software updates, and user notification, where the 
conventions on each platform differ more dramatically.

Python's native UI capabilities, on the other hand, give programmers 
the tools they need to write the core of their application using 
portable code while being able to write a UI (or UIs) that actually 
takes advantage of the underlying platform's features and that plays 
nicely with the underlying platform's conventions and interfaces - all 
without switching languages. I don't see having to maintain two or 
three UI codebases as being that much worse than riddling a single UI 
codebase with conditionals or extension points for handling each 
platform's idiosyncracies.

Fortunately for me and my opinions, Python is already shaped like that. 
PyObjC provides bindings for writing OS X applications; PyGTK and PyQt 
support Gnome and KDE respectively (as well as any other X11 desktop); 
PyWin32 provides passable support for Windows UIs, or you can use 
IronPython and .Net's GUI APIs. It is absolutely zero skin off of my 
nose if someone decides I'm utterly out of my tree, figures out that 
cross-platform GUIs are the future, and goes on to write an amazing 
pure-Python GUI stack that works everywhere with a colour monitor.

Cheers,

-o




More information about the Python-list mailing list