GUIs - A Modest Proposal

[Stephen Hansen]

On 6/10/10 2:20 PM, rantingrick wrote:
> However, i think you'll also agree that GUI
> has been (and continues to be) an ever evolving beast. With many,
> many, library's to choose from and nobody can agree that *this* or
> *that* GUI library is better. 

I fail to see how the above statement (which I neither agree nor
disagree with; its loaded and there's multiple separate assertions that
don't really connect the way you want them to) leads to...

> As is evidenced by the lack of development for Tkinter. 

... this. I see no logic at all in how somehow this proves the previous
claim.

Tkinter, the Python wrapper, is not "developed" because it is largely
"done". It is an interface to the Tk library, which is indeed developed,
and Python does indeed get regular updates to it. That the Python
wrapper is not terribly "pythonic", and has an implementation detail of
going through TCL: so what? Somehow you think that makes it impure,
dirty, lessens Python. It doesn't.

The API may not be wonderful, but its not anti-Pythonic, either. Its
just sorta 'eh'.

> But with Tkinter there is a larger problem,
> TclTk! Even Tk is not a full featured GUI library, much is to be
> desired. So with all that in mind i ask you again...

There is no larger problem except in your mind. The additional
dependency of TCL seems no more onerous then the dependency of pywin32,
pyobjc, let alone pygtk, and such... and on linux it seems just as
likely to be either already present or trivially installed as any of those.

And so what, Tk is not a full featured GUI library? Since when did that
matter to you? Your entire argument has been for a non-full-featured
library. Something simple. You can't go from there then put a black mark
against Tkinter for being there already.

Tk has a few very powerful features. And a lot of very easy ones. It
fulfills a lot of people's needs just fine. For those that it doesn't,
well -- they'll soon find wxPython, PyQt, or whatever else is out there
these days.

> Since GUI's are not as easy to maintain due their inherent fluidity
> (unlike other "more static" modules)... and since the process by which
> they are maintained is excruciatingly slow... why then include a GUI
> at all? Free up pydev and send Tkinter to the bitbucket! But if you
> *do* decide to include a GUI, should it not at *least* be based on the
> native widgets like PyGUI? I think going native is going to be the
> only answer here. When in Rome...

Tkinter requires basically little or no maintenance, IIUC. There was a
little bit that had to be done in Py2->3, but otherwise-- Martin Leöwis
said he just updated the latest libs when he made a new major release.
He didn't seem to express it was a major burden.

Therefore, your argument that it is somehow a burden fails. With that
failing, there's no reason to remove what is already present: key to the
stdlib is stability, and stability also means that once something is in,
it doesn't go -out- without a -very- good reason: and almost always, a
better replacement ready immediately (and with a very clear upgrade
path). Consider the recent optparse->argparse discussions on python-dev.

Stdlib modules don't get just dumped on a whim.

Native widgets are all fine and dandy, to a point. PyGUI is all fine and
dandy, and when and if it's ready to do everything Tkinter does, if its
dependency situation is more positive then Tkinter's, and it brings some
other positives-- a good pythonic API, maybe some other carrots-- then
maybe talk of replacing Tkinter is appropriate.

As it is, it doesn't seem to me that its there yet. Not that I am deeply
familiar with PyGUI, mind you.

-- 

   Stephen Hansen
   ... me+list/python (AT) ixokai (DOT) io

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20100610/7d3570f0/attachment.sig>