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

Kevin Walzer kw at codebykevin.com
Sun Jan 16 13:59:19 EST 2011


On 1/16/11 1:27 PM, rantingrick wrote:
> On Jan 16, 11:39 am, Kevin Walzer<k... at codebykevin.com>  wrote:
>
> First of all welcome back to the discussion Kevin. You and i both
> appreciate and use Tkinter extensively and your input is most welcome
> here. You are a smart and level headed fella which makes for good
> discussion. Thanks for that! Ok, let the battle begin! :-)

Glad to be back.
>
> Wrong. Even with the hodgepodge of third party downloads and extension
> packages Tkinter cannot hold a candle to the professional quality of
> wxPython. Again i urge you to at least download the demo and see for
> yourself. WxPython is a massive library of almost any widget you can
> imagine using in the 21st century. All of the hard work has been done
> for you, no need to create your own custom widgets again and again. Do
> yourself a favor and download the demo. Here it is again...

I'm quite familiar with the wxPython demo. I've got the latest 
incarnation, from 2.9.x, installed on my machine. The latest version is 
quite nice, especially with the AUI widgets, and the underlying 
wxWidgets libraries are finally up-to-date on my Mac as they access the 
Cocoa frameworks, rather than the deprecated Carbon frameworks.

However, wxPython does lack some things on my Mac, which I have been 
able to implement in Tk. Specifically:

1. My Tkinter apps can access the Mac's Services menu, which provides a 
form of inter-application communication that allows one application to 
send data to another and have the target application perform some 
manipulation of that data. wxPython does not support this feature of the 
Mac.

2. Any wxPython application that attempts to display the filesystem on 
the Mac looks out-of-place because wx has no support for displaying 
native icons on the Mac, though it can display them in Windows.  Tk on 
the Mac has a few different ways of displaying icons natively.

3. wxPython applications do not make use of common window flags on the 
Mac, such as sheets and drawers. Tk provides native support for some of 
this, and extension packages provide further support.

So: while wxPython is quite capable of creating handsome applications, 
even on the Mac, there are subtle things about wxPython applications 
that make them feel not quite native, regardless of how rich the overall 
widget set is.

Part of my preference for Tkinter is that, under the hood, Tk is much, 
much easier to extend than wxWidgets. I have written several libraries 
in Objective-C, using Tk's C API, that hook into various aspects of 
native Mac functionality, such as the Services menu. Once this 
functionality is accessible from Tk, it's trivial to write a Python 
wrapper for it; it's often as easy as 'root.tk.call', 'nativetclcode here'.

As I understand it, extending wxWidgets requires coding in C++, and then 
you'd need to run your code through SWIG in some fashion to be able to 
access it from wxPython. In short, there are several more steps, and 
it's likely more complicated at each step.  For various reasons, the 
things I think are missing from wxWidgets (native icons, sheets/drawers, 
etc.) are not considered important by the core wxWidget developers, or 
implementing them is a low priority.

> Well we need the license lawyers to weigh in on that aspect. If
> wxPythons license is weighed and found wanting then we must consider
> something else. However, i will tell you that nothing else exists that
> can match the maturity, cross-platform, and feature rich-ness of wx.
> If someone knows of any such package by all means speak up!

Well, PyQt comes to mind. Qt is better at native Mac implementation than 
wx in many respects (window flags, accessing native Mac icons), and 
overall it is a richer framework (its support for WebKit is amazing), 
but PyQt remains licensed under the GPL, which makes it off-limits for 
the stdlib. Plus, there are other Python-Qt implementations out there 
(PySide) that may claim some of PyQt's mindshare in the future.

--Kevin

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



More information about the Python-list mailing list