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

[rantingrick]

Tkinter: The good, the bad, and the ugly!
-----------------------------------------
An expose by rantingrick


----------------------
 The Good
----------------------
Back in the early days of Python --when this simplistic beauty of
programming bliss we enjoy today was just a tiny glimmer of hope in a
archaic world plagued by dark forest of braces and jagged caverns of
cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
foresight to include a simplistic GUI toolkit that we call Tkinter
into the stdlib. And he saw that it was great, and that it was good,
and so he rested.

And when the first python programmers used this gift handed down from
the gods they were pleased. They could see that all of the heavy work
of cross-platform-ism landed square on the shoulders of TCL/Tk and all
Python had to do was wrap a few methods to wield the beast we all know
as graphical user interfaces.

Life was good, people were happy...but darkness loomed on the
horizon...


----------------
 Enter the Bad
----------------
However as we all know there exists no real Utopian bliss without many
pitfalls and snares.  Since Tkinter is just a wrapping of some TclTk
calls the people realized that they are now at the perilous mercy of
another group of developers (psst: thats the TCL folks!) who have only
their own goals and dreams in mind and could care less for the
troubles of others. They realized that Tkinter was lacking. However
this lacking was not Tkinters fault, no, the fault lye with TclTk. And
to compound these problems they also realized that in order to fix the
design problems inherit in TclTk they must learn an obscure and mostly
useless language... TclTk!!

--------------------------------
 Utterly destroyed by the Ugly!
--------------------------------
And then the people became very angry... "What a double cross!" they
chanted. Why should we learn a language like TclTk just to fix
problems that the TclTk folks need to fix themselves? Would not that
time be more wisely spent in looking over code that is 100% Python and
modifying it? Not only would our community benefit but we can
propagate the maintainece and/or improvements to a wider group of
folks by removing the high entrance requirements. When we elevate
every python programmer to a PythonGUI maintainer then we will have
achieved community nirvana!

We have now reached a point where the very simplicity we have embraced
(Tkinter) has become a stumbling block not only for the users of
Tkinter, but more devastating is the damage this TCL/Tk monkey has
done to keep our fellow Python brothers and sisters from learning how
a GUI kit works (behind the scenes) with each OS to bring all this
graphical stuff to life.

------------------------
 So what should we do?
------------------------
The answer is simple. We need a 100% Python GUI. A GUI coded in Python
from top to bottom. A GUI that is cross platform to the big three
(Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
also a GUI that can be manipulated by the average python programmer. A
GUI that not only teaches the fundamentals of using a GUI, but also a
GUI that teaches how a GUI works under the hood

Then and only then will Python be truly what GvR intended. I want
everyone here to consider what i am proposing and offer some opinions
because it is time for change.