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

[rantingrick]

On Jan 16, 12:59 pm, Kevin Walzer <k... at codebykevin.com> wrote:

> 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.

Glad to hear that! :)

> 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.

Ok so you're complaining about a "Mac specific" missing functionality?

> 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.

Ok, even if it looks "out of place" this is another "Mac Specific"
problem.

> 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.

"Mac Specific"

> 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.

I think the moral of this story is simple. Mac decided to implement an
OS that is completely different from the others. Also as you well know
Macs are at the bottom of the stack in terms of popularity. Windows,
Unix, Linix, Mac, in that order. Sure you "may" have the most
pretentious OS on the planet. However you must accept that with a
small user community also comes an equally small developer community.
And even if i give these "minor complaints" 100% merit you still only
have 0.25% of the market you are representing, so you lose the
argument in a big way. Your complaints are but a drop in the
proverbial bucket. But don't fret my friend with wxPython in the
stdlib i'll bet you could persuade or even help to bring Mac support
for these "small" annoyances.

> 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 this is something that you need to attack at the source Kevin.
Specifically i mean for you to join the WxWidgets group and start a
grassroots movement for better mac support. Barking about a few small
"annoyances" with an OS that has a "last ranked" standing is a bit
bombastic to say the least. Yes?

> 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.

I am willing to support any GUI library that will move us forward and
TclTk is dead weight. I like the feature rich nature of wx however i
will consider others if a "compelling" argument is put forward.