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

[Adam Skutt]

On Jan 1, 5:03 pm, rantingrick <rantingr... at gmail.com> wrote:

> I actually like Tkinter's simplistic API. I especially love Tkinter
> geometry management! However i realize that TclTk is lacking and
> because of that fact we will always be at the mercy of another
> community. This bothers me, and it should also bother you.

It's true of any widget library out there.  It's inescapable.  Python
bindings to the native widgets are still at the mercy of MS and Apple
(and GTK+ or Qt, whomever you pick for UNIX ).  We've seen how much
Apple cares about 3rd-party developers, and while MS at least cares,
you never know when or how they'll implement something.  Look at the
mess with the ribbon, for example.  There's the Office version, an MFC/
Win32/COM version, and a WPF version.  Not only do all three have
slightly different APIs, they all behave slightly differently too
w.r.t the end-user.

Even a "pure python" GUI library cannot get rid of this problem
entirely.  Witness that Xlib is (slowly) being deprecated for XCB[1].
It's possible, though unlikely, that MS will eventually stop providing
new functionality through Win32 and/or make radical changes.  It's
also possible, though unlikely, that Apple will eventually pull
another stunt on the level of deprecating Carbon and rip apart
Quartz.  Any of those changes would require drastic implementation
changes on the part of the python GUI library.

It's inescapable, so it's generally best not to worry about it.

> However be aware that GUI's libraries are large beasts. You cannot
> cram everything into the stdlib.

Who says?  Java does.  Android does.  Microsoft does.  Apple does.

> So what should go into the stdlib then?
> Well only a very limited subset of widgets. Some might say that
> you will be limited with a limited subset, well i must agree with
> argument :). Some might also say that a glass half full is also half
> empty, duh!

No, not 'duh'.  You have to explain what the utility of doing such a
thing is, as the utility is not apparent in the least.  You also need
to explain how this is actually accomplished.  I don't see it as a
trivial task, especially if the implementation path is to wrap
something else.  What we have now is about as minimal as things are
going to get.

>
> Everyone needs to realize that the only reason for having ANY GUI in
> the Python stdlib is for ease of learning and also for "batteries
> included". We just want the basics of a GUI with an extension library
> available for download. There are two major advantages to this
> setup...
>
> 1. The basics never change. So the Python "stdlib GUI module" becomes
> a "set it and forget it" module. The Python "GUI extension library"
> can change all it wants and Python remain backwards compatible.
>

No, I don't see how this follows in the least, especially if the
implementation path is, "wrap something else".  But even in the pure
Python case, most (nearly all) GUI applications will rely on the
extension library, so it will not be able to change all it wants.

> 2. By relegating the bloat to an external download the stdlib is kept
> as small as possible.
>
It's not apparent why this is desirable to me.  Even if we take it as
a tautology, you need to show the value and means for splitting up a
GUI library.  Your cutting may result in their being more value by not
including a GUI at all.  Trivial proof: if everyone ends up needing to
download the extension library anyway, you incur no cost for anyone
and make the standard library smaller by not including any GUI
functionality.

So go on, show us a minimized, functional widget set and what we can
do with it.  We're all pretty eagerly awaiting such a thing.

> There is no real Tk::Grid. Sure as someone suggested you can mimic a
> grid with another widget, it's just lipstick on a pig really. Go and
> check out the wx::Grid with all its wonderful capabilities and then
> you shall be enlightened!
>

TkTable seems to do everything wx::Grid[sic] can do.  I didn't check
fully, as it's your claim, so your responsibility to show the
inadequacies, especially since you don't even seem to be aware of
TkTable's existence.  The biggest missing feature seems to be DnD
support, AFAICT.  BFD to me, since I've never actually encounterd DnD
support worth a damn ever and have always ended up doing it manually.

> Wx is by far the best choice for Python. A small subset of wx widgets
> in the stdlib and ONE (and only one!) downloadable extension library.
> Yes the stdlib widgets are only going to cover the most minimal of
> GUIs -- for learning purposes, utilities, or just simply toys) If you
> plan to do professional GUI work than package the extension library.
> It's very simple really.
>

Why split it, if you use wx[sic]?  All that saves you is a few .py/.c
files in the stdlib.  You still need the full wxWidgets install to
build even the "minimal set", which is pointless and stupid.  The
costly part with wxWidgets is depending on the native library, not the
amount of code in the stdlib.

Again, do you think the various Tk bindings fall along library lines
just for fun, or that there just possibly might be a method to the
madness?

> Geesh! Now i know how the early scientist felt when trying to convince
> the lemmings that the earth is not flat!
>
> Flatearther said: """You heritic!. If the earth were round we would
> fall off the bottom!"""

You can pretend you're being persecuted all you want, but it really
only furthers the opinion that you're completely and fully
disconnected from reality. The torches you see are entirely of your
own imagination.

Adam

[1] In the case of X, you could write your own protocol library, but
then when the protocol changes...