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. -- http://mail.python.org/mailman/listinfo/python-list
