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

[Kevin Walzer]

On 12/30/10 10:24 AM, rantingrick wrote:
> On Dec 30, 8:59 am, Kevin Walzer<k... at codebykevin.com>  wrote:
>> On 12/29/10 6:58 PM, rantingrick wrote:
>
>> Any GUI framework is going to require at least some heavy lifting in C,
>> C++ or Objective-C (depending on the platform). A pure-Python approach
>> to GUI development is technically infeasible.
>
>
> This is a very good point Kevin however i would much rather spend time
> learning a language like C --which is hugely useful in many
> contexts!-- than to waste one second of my time on a domain specific
> language like TCl which is created only for drawing GUIs using Tk. I
> think everyone can agree that learning C is of benefit far more
> benefit to anyone in the programming field. Also one could argue that
> C and Python are very similar. However Python and Tcl are like night
> and day.

Tcl is not a domain-specific language for creating GUI's. Tcl is a 
full-featured, general-purpose programming language that is a peer to 
Python in its capabilities, and surpasses Python in some respects.

>
> This monkey on our back (TclTk) is dead weight. We need to free
> ourselves of this GUI prison and bring Python into the 21st century.
> Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be
> complete or extensible within our community.

In 2010, Tk only lacks two major features common to GUI toolkits:

1. A cross-platform printing API. This is mainly an issue on Windows, 
which lacks a rich command-line printing framework. The canvas widget 
can generate PostScript, and the text widget can export its contents to 
a text file, and then "lpr" can handle the rest on Unix systems 
(including the Mac). Still, if you want native dialogs and full 
integration with a platform-specific printing API, you will have to 
utilize one of several, incompatible, platform-specific extensions.

2. A robust widget for HTML display. The old TkHTML widget (authored by 
D. Richard Hipp, the author of SQLite) works, but it's very dated (last 
updated in 2002) and lacks modern features like CSS support. An effort 
to produce a next-generation HTML widget, TkHTML 3, yielded an 
alpha-quality widget that is enormously complex, somewhat buggy, and 
little used.

These days, Tkinter has pretty much everything that other GUI toolkits 
have: tree views, multi-column listboxes, plus all the basics, available 
through the core widget, the themed ttk widgets, or extension packages. 
Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app 
is ugly, that's a reflection on the developer, not the toolkit.

>
> There is no OpenGL canvas readily available. Sure you can use Togl (as
> i have successfully!) however Togl is old and unmaintained. Any GUI
> library in this day and age must support opengl out of the box!

Togl is still developed. One of its maintainers, Greg Couch, is a 
developer on the UCSF Chimera project (a Python-Tkinter based molecule 
viewer).

> Look, losing Tkinter will be very painful for me as i have tons of
> code written already. However the more i learn about Tkinter the more
> i realize how Tkinter is a dead end street. Why let a rotting dinosaur
> stagnate in the stdlib? Anybody that has foresight knows Tkinter is
> dying and cannot be revived. It is time to move on. Tkinter served us
> well for a time but we must let go and evolve -- lest we wither and
> die ourselves!
>

I have nothing against other toolkits, and if one happens to catch on, 
fine. But your assertions that Tkinter/Tk is dying have no basis in 
fact. I'm an active developer in Tk with both Tcl and Python, and the 
reason I have stayed with the toolkit is precisely because it isn't 
dying. Check out the screenshots at my website--all those GUI's are 
developed in Tk. Here's one in Tkinter/Python:

http://www.codebykevin.com/phynchronicity-running.png

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com