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.

 

[Katie T]

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.

What's your opinion of the other gui toolkits with Python bindings
like PyQt and PyGtk?

Katie

 

[rantingrick]

What's your opinion of the other gui toolkits with Python bindings
like PyQt and PyGtk?

Hello KateT,

Well i like wxPython as it is quite well rounded but we all know it
has some shortcomings too and wx is far too bloated for the stdlib!
pyQt and pyGtk i cannot comment on because i have no experience with
them.

However i need to stress that my intention is towards a 100% Python
GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
Python GUI. The only thing that i know of at this point is pyGUI
although there are probably others. Allowing the average Python
programmer the ability to read OS specific calls written in Python
would not only benefit their GUI knowledge, but also there knowledge
of OS's in general.

I guess you could sum it as "Getting the most bang for your community
buck".

 

[Gerry Reno]

wxPython looks good but I don't see anyone developing support for things
like smartphones.

Also, what do you think about frameworks such as pyjamas? It lets you
write in python and compiles everything down to Javascript so it can be
used across the Web as well as on the desktop.

 

[Octavian Rasnita]

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.

Yes, for that time it was good.

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

Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.

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

So it should be a kind of SWING library made in Python, right?
It is a good idea, but it should not have the problems of SWING and in that case it would be very hard to do.

First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.

WxPython is the best GUI because it is fast, even though it is bloated, it uses the native GUI elements on all those 3 operating systems and a relatively good accessibility for screen readers.

But WxPython still have problems because not all operating systems native GUIS offer the same widgets and features and those features custom-made don't respect the accessibility standards.

WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.

Octavian

 

[Octavian Rasnita]

What's your opinion of the other gui toolkits with Python bindings
like PyQt and PyGtk?

Katie
--

They are not accessible at all for screen readers, so the programs that still use them won't be accessible to all potential users.

Octavian

 

[rantingrick]

wxPython looks good but I don't see anyone developing support for things
like smartphones.

No wx is not the answer to our problems

Also, what do you think about frameworks such as pyjamas?  It lets you
write in python and compiles everything down to Javascript so it can be
used across the Web as well as on the desktop.

Hmm, this is like two double edged swords smashing one another in
battle.

Sword One: On one hand web frameworks are going to be really big soon
-- however legacy GUI's are not going away any time soon!

Sword Two: On the other hand web frameworks provide awesome cross
platform ability that is surly only going to get better as time goes
-- however i utterly hate JavaScript (although much worse web
languages exist!). And sending requests back and forth between Python,
JavaScript, and BrowserX is also a real PITA. Because even though
everyone knows this is coming all the major browsers are trying to
insert their API into the mix. So that Joe Scripter has to write code
that is compatible between many browsers. Until the world agrees on a
unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of
drunken sailors at the helm.

I believe pyjamas has a bright future in the web playground, however
we still need to focus our community efforts towards a Python based
GUI. I can see a pythonGUI and pyjamas existing side by side in mutual
harmony for many years.

 

[Steven D'Aprano]

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

Your ideas are intriguing to me and I wish to subscribe to your
newsletter.

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

I look forward to seeing this software of yours. Let us know when you've
got some code, and not just empty talk.

 

[Adam Skutt]

First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.

Which is where the contradiction comes into play: to use the actual
native widgets, you have to write some C (or Objective-C). Of course,
on Windows, people have faked the native widgets so many times that
you could probably get away with it if you made a really good fake,
though there are still a lot of gotchas that go with that
(accessibility and all that "other stuff"). On Linux, it's not like
there's really a standard anyway. That leaves OS X as the really
troublesome one.

WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.

Speed is not even on the list of things I'd be worried about first.

Adam

 

[Kevin Walzer]

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

Any GUI framework is going to require at least some heavy lifting in C,
C++ or Objective-C (depending on the platform). A pure-Python approach
to GUI development is technically infeasible.

 

[Kevin Walzer]

This is a very good point Kevin however i would much rather spend time
learning a language like C --which is hugely useful in many
contexts!-- than to waste one second of my time on a domain specific
language like TCl which is created only for drawing GUIs using Tk. I
think everyone can agree that learning C is of benefit far more
benefit to anyone in the programming field. Also one could argue that
C and Python are very similar. However Python and Tcl are like night
and day.

Tcl is not a domain-specific language for creating GUI's. Tcl is a
full-featured, general-purpose programming language that is a peer to
Python in its capabilities, and surpasses Python in some respects.

This monkey on our back (TclTk) is dead weight. We need to free
ourselves of this GUI prison and bring Python into the 21st century.
Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be
complete or extensible within our community.

In 2010, Tk only lacks two major features common to GUI toolkits:

1. A cross-platform printing API. This is mainly an issue on Windows,
which lacks a rich command-line printing framework. The canvas widget
can generate PostScript, and the text widget can export its contents to
a text file, and then "lpr" can handle the rest on Unix systems
(including the Mac). Still, if you want native dialogs and full
integration with a platform-specific printing API, you will have to
utilize one of several, incompatible, platform-specific extensions.

2. A robust widget for HTML display. The old TkHTML widget (authored by
D. Richard Hipp, the author of SQLite) works, but it's very dated (last
updated in 2002) and lacks modern features like CSS support. An effort
to produce a next-generation HTML widget, TkHTML 3, yielded an
alpha-quality widget that is enormously complex, somewhat buggy, and
little used.

These days, Tkinter has pretty much everything that other GUI toolkits
have: tree views, multi-column listboxes, plus all the basics, available
through the core widget, the themed ttk widgets, or extension packages.
Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app
is ugly, that's a reflection on the developer, not the toolkit.

There is no OpenGL canvas readily available. Sure you can use Togl (as
i have successfully!) however Togl is old and unmaintained. Any GUI
library in this day and age must support opengl out of the box!

Togl is still developed. One of its maintainers, Greg Couch, is a
developer on the UCSF Chimera project (a Python-Tkinter based molecule
viewer).

Look, losing Tkinter will be very painful for me as i have tons of
code written already. However the more i learn about Tkinter the more
i realize how Tkinter is a dead end street. Why let a rotting dinosaur
stagnate in the stdlib? Anybody that has foresight knows Tkinter is
dying and cannot be revived. It is time to move on. Tkinter served us
well for a time but we must let go and evolve -- lest we wither and
die ourselves!

I have nothing against other toolkits, and if one happens to catch on,
fine. But your assertions that Tkinter/Tk is dying have no basis in
fact. I'm an active developer in Tk with both Tcl and Python, and the
reason I have stayed with the toolkit is precisely because it isn't
dying. Check out the screenshots at my website--all those GUI's are
developed in Tk. Here's one in Tkinter/Python:

http://www.codebykevin.com/phynchronicity-running.png

--Kevin

 

[Stefan Behnel]

rantingrick, 30.12.2010 00:58:

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

I hope you invested as much time into writing this "expose" as you did
searching the web before writing it.

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

(the site is currently broken for me, you can use the following instead:

http://webcache.googleusercontent.c....cosc.canterbury.ac.nz/greg.ewing/python_gui/

Stefan

 

[Kevin Walzer]

rantingrick, 30.12.2010 00:58:

I hope you invested as much time into writing this "expose" as you did
searching the web before writing it.

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

(the site is currently broken for me, you can use the following instead:

http://webcache.googleusercontent.c....cosc.canterbury.ac.nz/greg.ewing/python_gui/

This library isn't much different from other Python GUI toolkits--it's
dependent on underlying, rather large, platform-specific
implementations--but it provides an even higher level of abstraction. On
the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11,
pygtk. In short, it's a wrapper over other wrappers.

 

[rantingrick]

I hope you invested as much time into writing this "expose" as you did
searching the web before writing it.

And ditto to you. If you would have followed the thread so far, in my
second post i said...

"""However i need to stress that my intention is towards a 100% Python
GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
Python GUI. The only thing that i know of at this point is pyGUI
although there are probably others."""[198:203]

 

[Stefan Behnel]

rantingrick, 30.12.2010 17:02:

in my second post i said...

"""However i need to stress that my intention is towards a 100% Python
GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
Python GUI. The only thing that i know of at this point is pyGUI
although there are probably others."""

Sure, fine, just making sure you know the terrain. If that's not enough for
you, you should follow Steven's advice to get started implementing
something, because this may become a lengthy undertaking.

Stefan

 

[python]

These days, Tkinter has pretty much everything that other GUI toolkits
have: tree views, multi-column listboxes, plus all the basics, available
through the core widget, the themed ttk widgets, or extension packages.

***Today, there's no excuse for developing an ugly Tk GUI--if a new Tk
app is ugly, that's a reflection on the developer, not the toolkit***

+1 (emphasis added)

Other tk/ttk benefits:
- Very stable
- Cross platform (w/native look and feel via Python 2.7/3.1 ttk)
- Light weight
- Easy to distribute
- Extensible

Regarding lack of print support: All GUI frameworks suck in this regard.
The best approach is to use a technology designed for generating hard
copy output - something like PDF, TeX, or RTF library.

Malcolm

 

[rantingrick]

Tcl is not a domain-specific language for creating GUI's. Tcl is a
full-featured, general-purpose programming language that is a peer to
Python in its capabilities,

Anybody can gloat and gush about their favorite programming language
however what separates fantasy from reality is evidence of these
"theories". Or rather, Illusions of grandeur!

and surpasses Python in some respects.

The only thing that Tcl has over Python is building Tk GUI's. Please
post evidence otherwise if you dare! In the meantime i will not be
holding my breath.

In 2010, Tk only lacks two major features common to GUI toolkits:

1. A cross-platform printing API. This is mainly an issue on Windows,
which lacks a rich command-line printing framework.

True windows has no "one-liner" "send-to-print-function" but what it
does have is GDI and GDI+ which are far more powerful for windows
programmers. Sure you may have to issue a few dc.MoveTo(x,y) and
dc.LineTo(x,y) and dc.TextOut(blah) but what is so hard about that?
Really, if you want a one liner just wrap up some Python code into a
nice interface. This argument is either completely bogus or utterly
idiotic.

2. A robust widget for HTML display.

The fact that Tkinter lacks an HTML widget is of no concern to me.
Actually if i had a choice of including HTML support or not i would
opt for not. Why? Because the simple fact is that Python needs a
simplistic GUI and not bloat-ware in the stdlib. HTML widgets, handy
dandy anolog clocks, happy faces and dancing bananas widgets belong in
3rd party extension library's and not in the Python stdlib. However we
must make sure that any GUI we support not only has these widgets
available as extension libraries but that these libraries are
currently maintained. If you are going to complain about lacking
widgets then Togl would be a good starting point.

These days, Tkinter has pretty much everything that other GUI toolkits
have: tree views, multi-column listboxes, plus all the basics, available
through the core widget, the themed ttk widgets, or extension packages.
Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app
is ugly, that's a reflection on the developer, not the toolkit.

Yes Tk is not all bad for TclTk, however it IS all bad for Python. Let
the Tcl folks use Tk and we will use a python GUI. Nuff said.

Togl is still developed. One of its maintainers, Greg Couch, is a
developer on the UCSF Chimera project (a Python-Tkinter based molecule
viewer).

Have you seen the code in togl.py yourself? I mean really read it from
beginning to end? It's a hodgepodge of poorly written code. I know
this because i had to update the code myself for one of my projects.

Look i have nothing against you Kevin. However i know you and Tkinter
(and Tcl) are in bed together. So this is more of a *personal*
decision for you instead of a *community* decision. Whether Tkinter
exists in the stdlib or not should't matter to you because you can
just download it from a 3rd party site.

And *if* enough people really love Tkinter as you suggest then
removing it will not kill it. However you know as well as i do that
Tkinter is a drain on this community and the only thing keeping it
alive is the fact that it is packaged in the stdlib. Once Tkinter is
removed it will die as it should and something better will take it's
place. Something more Pythonic. And most importantly something that is
completely and totally under the direct control of the Python
community.

 

[rantingrick]

This library isn't much different from other Python GUI toolkits--it's
dependent on underlying, rather large, platform-specific
implementations--but it provides an even higher level of abstraction. On
the Mac, it is dependent on PyObjC;  on Windows, pywin32; and on X11,
pygtk. In short, it's a wrapper over other wrappers.

hmm. And what is Tkinter exactly? And more importantly how is it
better than pyGUI (design wise)? And even more importanly, how will it
be better in the long run? Is this just more FUD Kevin "Gates"?

 

[python]

Octavian,

Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.

Might this package help? (I have no experience with this project)

Tka11y 0.1.1 - accessibility-aware Tkinter
http://pypi.python.org/pypi/Tka11y

Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
the current control and/or its contents?

I would love to hear from anyone using either of techniques ... or other
techniques or screen reader products ... to make their Tkinter
applications accessible to low vision/blind users.

Malcolm

 

[Octavian Rasnita]

From: <[email protected]>
Subject: Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!)

Octavian,


Might this package help? (I have no experience with this project)

Tka11y 0.1.1 - accessibility-aware Tkinter
http://pypi.python.org/pypi/Tka11y

Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
the current control and/or its contents?

I would love to hear from anyone using either of techniques ... or other
techniques or screen reader products ... to make their Tkinter
applications accessible to low vision/blind users.

Malcolm

Thank you very much for those projects! I will test them.

Unfortunately they are not a solution because if I want to create an accessible app I can do it using an accessible library, but if the other programmers of the world use a non-accessible by default GUI, than their programs won't be accessible, or they will offer a limited accessibility like Java Access Bridge offers to SWING-based apps.

If Tkinter would use that project that should offer the accessibility by default, that would be a real solution.

Octavian