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

[rantingrick]

On Jan 20, 10:36 am, rusi <rustompm... at gmail.com> wrote:
> On Jan 20, 5:30 pm, Bill Felton <subscripti... at cagttraining.com>

> > With some hesitation, I feel a need to jump in here.  
> This thread is now at 239 posts (and so I too hesitate...)

Why hesitate? Whether it be one post or a million posts, if you have
ideas, opinions, or suggestions then by all means jump in and share
them. If your words are FUD, not based on fact, or just completely
ignorant, don't worry, someone will correct you :-)

> The arguments for size, dependencies etc are what may be termed
> 'sys-ad' perspectives. The questions of 'it looks nice/ancient etc'
> are user issues. What about some programmer perspective?

Size is very important. Dependencies are very important (within
context!). So too are aesthetics just as important when considering a
"graphics" module. In the end, Python should aim to bring the best
looking, most advanced (but well tested!), scalable modules we can
muster into the stdlib. At the time of it's inclusion Guido believed
Tkinter was the best choice -- and i agree with him! However we are
talking now about ~20 years of time between then and now. Is anyone so
bombastic as to suggest that GUI has not changed significantly in that
time. And likewise, is anyone so bombastic as to suggest that the
lowly Tkinter module (and even worse TclTk) is representative of 21st
century GUI programming?  Heck, when Tkinter was added GUIs where just
in their infancy as far as popular adoption is concerned! TclTk have
lacked vision from the beginning. NEWSFLASH! They did not support
themes until version 8.5! (~2009) And they still have much work to do
if they ever want to compete with the likes of wxPython however i know
thay will never reach that level of sophistication. TclTk as a
community are not concerned about keeping up with he times, so be it!
However we should not degrade "our" stdlib and "our" community with
such backward thinking communities. We must move forward. We must pull
our heads out of the sand or mentality will be our undoing.


> Using something like VB-in-.NET allows a programmer to put up
> significant uis with close to zero coding. Many programmers would
> look down on these as 'non-programmers'

Well i don't look down on these folks i just feel they are missing out
on the richness and abstract thinking that creating the GUI mentally
evokes. However. I believe it would be of great benefit to have a
graphical GUI builder as part of any GUI package we consider for the
stdlib. Do i think it should be IN the stdlib? Probably not due to
size. But the fact that it is available for those who would like it to
be is great. My biggest complaint with Tkinter is that it lacks so
much functionality (even outside the stdlib!) that you really end up
wasting your time learning and using it. Because eventually you will
be forced to throw away everything you've learned and written and
convert to something else.


> So the (to me) relevant questions relating to GUIs are for example:
> 1. Is glade (and others such) equal to wxpython, tkinter and other
> such 'backends'? 2. Can glade (or whichever is the best such tool
> today) compare to VB in .NET or does it look like a bad joke in
> comparison (I guess the current thing may not be VB but WPF but I
> dont want to pretend to know too much about windows)

I think we need to add a graphical GUI builder to the list of
important attributes of a 21st century GUI library. Not the most
important, but still quite important. Especially if we want to
"market" Python as a GUI language. And I am not saying we should
market Python that way.

So the attributes we must demand of a 21st century GUI library are a
follows:

 * Quality Documentation (our problem really)
 * Cross Platform (their problem)
 * Rich Full Featured Widget Set. (their problem)
 * Simplistic API (our problem)
 * Scalability (their problem)
 * Accessibility (their problem)
 * Graphical GUI Builder. (Either or)

Also some attributes related to the "Big Picture" of GUI and Python:

 * Mobile and Web support