GUIs - A Modest Proposal

[Stephen Hansen]

On 6/10/10 9:34 AM, rantingrick wrote:
> Like it not (And i'm talking directly to all the Unix hackers here!)
> Win32 is here to stay! You should have realized that years ago! And
> likewise, like it or not, GUI is here to stay. You should have also
> realized that years ago (although we may be supporting web interfaces
> soon...same thing really). If you wish to hide your head in the sand
> and ignore these facts hoping that the "old days" of command line and
> no windows platform will return, well thats not going to happen. The
> rest of us are going to move forward and hope that eventually you will
> see the light and tag along.

You're bordering very near "silly" now. Drop the rhetoric, it doesn't
actually help your case, argument, or position in the least. No one
thinks GUI's are going away. No one thinks win32 is going away.

Everytime you make a statement like this, you just sound daft.

Its not a question of those things going away. Its a question of what
exactly belongs in the standard library and what doesn't. Everything in
the world that is modern, current, or not "going away" does not need to
be in the standard library.

Why not include pywin32? Well the first question is: does Mark Hammond
even *want* it included? He has to offer it before the question can even
be considered, and assign copyright to the PSF. And after that
willingness is determined: its huge, and despite all of my *windows*
programming-- its what I get *paid* for in my day job-- I never needed
it except once.

So... uh, why again are we including it? Those people who need it, have
ready access.

Why not include wxPython and a very-easy-wrapper around it? Because
wxPython is also *huge* -- and also directly tied to the development and
release cycle of a third-party product (wxWidgets) which is *huge* in
and of itself-- you're now asking python-dev to effectively support
hundreds of thousands of lines of more code-- and a lot of it in a
language (C++) they may not be experts at (Python is C)! Not to mention
the only 'very-easy-wrapper' needs work, and there's no clear indication
anyone's willing to do the work

Why not include PyQT? Licensing makes it impossible.

Why not include PyGUI? Currently, its dependencies make it unsuitable,
but there's a question as to if its mature enough yet or not. I dunno,
I've never used it: it is *useless* to me. No offense to Greg meant.

Again: it has nothing at all to do with people not liking GUI's or
thinking GUI's are going the way of the dodo. It has to do with people's
ideas of what should or should not go in the standard library. Generally
speaking? Stuff that everyone or most people can make ready use of...
and while yes, doing GUI development is very, very common -- "GUI
development" is not a single monolithic thing. Different people have
some *very* different needs for what they get out of their GUI development.

For example: if you want to embed a CSS-capable web-browser into your
app? PyQT is actually your best option-- albeit a commercial one if
you're not open source.. wx/Python haven't yet finished WebKit
integration(*).

If you need some flexible or configuration-based user interfaces,
wxPython actually is a very solid solution, with its XML-based GUI
creation.

Neither of these things are very rare or even too terribly advanced.

The reason we do not embed any 'better' GUI then Tkinter into the
stdlib? There's several tools available for the job: and there is no
clear indication or agreement that one is better or more qualified for
inclusion over the others. At least, IMHO. I do not speak for python-dev.

> Tkinter and TclTk are dead! I use Tkinter and i can happily say that.
> And the ONLY reason i even use Tkinter is the fact that it's there in
> the stdlib! Remove the module and i will move on to something better.
> Tkinter is legacy software built on legacy software. It was the best
> choice way back when Guido forged the path. But now Tkinter has fallen
> into obscurity. Sure it's useful, i use it all the time. 

Rhetoric.

> But it's too
> large, too slow, and just too damn ugly to be part of "our" Python
> stdlib. 

It is fortunate that my Python is not ruled by the judgements of what
you think belongs in your Python.

There is clearly no "our" Python.

> Embedded interpretor, YUCK! If people want to use Tkinter they
> can download it as a 3rd party module, no harm done! But Tkinter is
> harming Python by disgracing Python's stdlib and slowing Python down.

Not just rhetoric, but silly rhetoric.

> PyGUI is still the front runner and has my vote until someone can show
> me a better option. I think if PyGUI where around circa 1995 Guido
> would have pounced on it like a hungry tiger on a wildebeest. Ask
> yourself what a Python GUI should look like, and what it should feel
> like. Then go and use PyGUI. The choice will be obvious.

PyGUI is indeed a solid project, and perhaps-- eventually-- a contender
for replacing Tkinter, once it works the kinks out and matures. Maybe it
is almost mature enough now? Maybe it needs more help? If so-- your time
would be better spent downloading it, using it, and offering some
patches, improving it -- then being silly and sounding like a religious nut.

Things don't go into the stdlib to mature.

-- 

   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/4d3a428a/attachment-0001.sig>