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