On 1/16/11 1:27 PM, rantingrick wrote:
On Jan 16, 11:39 am, Kevin Walzer<k...@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
--
http://mail.python.org/mailman/listinfo/python-list
