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

[Adam Skutt]

On Dec 31, 12:21 am, rantingrick <rantingr... at gmail.com> wrote:

> Of course a tiny widget set like this is not going to handle extensive
> GUI coding, thats a no brainer.

No, it's not going to handle any GUI coding except notepad.exe.
That's already been written, so we're left with no new application
that can be written with this proposed minimal widget set. Why do you
think Tix exists?  Why do you think there are Python bindings for it
in the standard library (to say nothing of a bunch of other additional
Tk controls)?

> But currently that is EXACTLY what we
> have to work with in the stdlib. Sure you have TIX and a few other
> extensions but they will never compare to the vast features of
> wxPython. Have you even aquinted yourself with wxPython Adam?
>

It is nothing of the sort even if you erroneously believe it is.  Have
you looked at Tix?  The fact you dismiss it away as some "extension"
like it is a leper really betrays your argument.  Others (not you)
have already described the legitimate deficiencies at length, I will
defer to them.

>  What i (and others) are proposing is to replace the existing Tkinter
> library with a matching wxPython libray. Then allocate the remaining
> wxPython library (which is ginormous btw!) into a 3rd party module
> available for download. My argument is that because wxPython is soooo
> feature rich. We will break the glass ceiling that exist now with
> Tkinter.
>

And what I pointed out is that wxWidgets (and Qt, and Swing, and Tk+Tix
+whatever, and every other GUI toolkit in existence) is so feature
rich for a reason: you actually need all of that stuff in order to
build rich, functional, useful GUI applications.  I think you'll find
that it's very hard to cut any functionality, even functionality
Python more or less entirely replicates (e.g., wxNet, wxODBC).  Why?
Because useful widgets rely on such low-level functionality (blame C+
+'s rather anemic standard library).

Moreover, even if you find things to cut, coming to a consensus about
what belongs outside of the stdlib will be difficult, if not
impossible; plus, it's considerable work for very little gain: I still
need a full install of wxwidgets to even build your useless minimal
set.  There's definitely no point in minimizing the python side of
things if it doesn't minimize the native code side of things.  Note
how the divisions with the Tk bindings follow the divisions of the
native libraries.

> Agreed! We need at least the same capability that Tkinter offers in
> the stdlib. Why would we sacrifice?

I don't know, but a sacrifice is precisely what you proposed.

> Thats not true. Yes all projects have faults of some kind. I am not
> suggesting that wxPython is some sort of "miracle" library. However
> anyone of average intelligence can do a side by side comparison and
> agree that wx is far superior to TclTk in many, many ways. If you have
> a valid argument as to how Tkinter is better feel free to share this
> information with us.

>From this claim I've forced to conclude you are not of average
intelligence, because you haven't managed yet to do an actual, factual
side-by-side comparison of wxWidgets and Tk. Here is one to start: the
native footprint of Tk has fewer dependencies than the native
footprint of wxWidgets.

> Adam, Adam. I feel you are desperately trying to inject negative
> energy into what is now the very beginnings of a healthy and positive
> community discussion on the future of Python's GUI library.

There's nothing positive about this discussion, since it's being
spearheaded by arrogance and ignorance.  It's highly improbable, in
fact, for this discussion to ever be healthy and positive without a
desperate attitude and behavior chance on your part.

Seriously, given that widget set you listed, what applications am I
supposed to write?  I can't write a web browser.  I can't write an
audio player.  I can't write a terminal.  I can't write an IM client.
I can't write a social media client/application/mashup.  I can't write
a web browser.  I can't write a game community client/launcher.  I
can't write office productivity applications.  So what can I write?

The fact your proposal shows you're entirely disconnected with reality
isn't my fault in the least, nor does it mean I'm "trying to inject
negative energy", nor that I'm "resorting to these wasteful and
vengeful tactics."

You want to be told your proposal isn't disconnected with reality?
Then propose ideas that actually have technical merit and that can be
actually accomplished, instead of proposing things that plainly lack
merit to anyone who's ever written a complicated GUI application
before and/or that are flat-out impossible.  Calling a bad proposal a
bad proposal is a positive thing, like it or not.  If you can't accept
that, you should consider a pastime that involves less criticism.

> If you do care about Python's future then you should get involved with this
> discussion in a positive way.

I have, I told you what you want to do isn't possible.  The fact you
don't want to nor like to hear that doesn't mean it is not positive.
A pure Python GUI toolkit isn't really possible.  Even if we agreed
that "pure" means something akin to AWT, it's still a really awful
idea (again, for really obvious reasons). Building something like WPF
would be worthwhile, but won't free you from needing a traditional GUI
library for quite some time, so you're still right back where we
started.

Replacing TkInter with some sort of minimized wxwidgets is a dumb idea
for some very obvious reasons, reasons that are obvious if you simply
look at a widget gallery and then the applications you run on your own
computer.  Quite honestly, if you're not capable of that, there's
little reason to believe you'll ever be able to bring forth a
coherent, cogent proposal.

Adam