GUIs - A Modest Proposal

[rantingrick]

On Jun 10, 3:06 pm, Stephen Hansen <me+list/pyt... at ixokai.io> wrote:

> And actually: things do go to the stdlib to die. Its actually a very apt
> description of exactly how things work. Once a module gets added to the
> stdlib, its sort of dead. Static. It might change, in this
> excruciatingly slow pace, with strict rules for compatibility over
> consistency. It takes years and years before you can fix a design error
> -- you have to wait until the next major release to put a new option in,
> do some deprecation (be it pending or regular, it depends), and then a
> whole new major release before you can finally be fixed.

Actually this is a very accurate description of the process, and i
agree. And some modules will do ok in this environment because by
nature they are static. 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. As is evidenced by the lack of
development for Tkinter. 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...

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