gui toolkits: the real story? (Tkinter, PyGTK, etc.)

[bramble]

What is the backstory to why Python includes Tk bindings, as opposed
to some other set of bindings?

I've written a few little Tkinter-based apps, and it's nice and
simple. I like it well enough. That said though, I keep feeling the
gravitational pull toward GTK+. I've been meaning to get the whole
glade+gtk+python thing happening with my own projects, as soon as time
allows. Is there resistance in the upper Python echelons to GTK
because of its LGPL licensing?

Reading Alex's Nutshell book, right off the bat he comments that "The
most popular Python GUI toolkit today is probably wxPython". But then
he goes on for 45 pages on Tkinter... Seems like he wanted to write
that chapter on wx instead...

WxWidgets, the last time I looked at it, seemed awfully like MS
Window's MFC. The licensing seemed vague at the time, and it looks
like wx contains an extra layer of GUI library, so I didn't spend any
real time on it. But, regardless, it seems to get good press among
python folk (I think I remember ESR noting how it was his GUI toolkit
of choice).

PyQt has had that issue (IIRC) about needing to pay for it for
commercial apps, so I can see how there might be resistance to it
being considered the "standard Python GUI toolkit".

So, it would seem to me that Tkinter *might* remain in Python proper,
but that I probably wouldn't see much effort put into it. Well, the
Python standard library docs tell a different story. There's stuff in
there about Tix, ScrolledText, turtle, and then the "other GUI
packages" doc page goes on about Python megawidgets (Tk-based) and
Tkinter3000 Widget Construction Kit (WCK). Wow. Looks like Tkinter is
still having serious support -- even though in that same doc at the
bottom notes, "PyGTK, PyQt, and wxPython, all have a modern look and
feel and far more widgets and better documentation than Tkinter."

So, that leaves me wondering, why is Tkinter still getting so much
focus in the Python standard library?

Maybe a better question is, how has Tk managed to keep beating up the
newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

 

[Paul Rubin]

Maybe a better question is, how has Tk managed to keep beating up the
newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

First-mover advantage.

 

[Benjamin]

What is the backstory to why Python includes Tk bindings, as opposed
to some other set of bindings?

I've written a few little Tkinter-based apps, and it's nice and
simple. I like it well enough. That said though, I keep feeling the
gravitational pull toward GTK+. I've been meaning to get the whole
glade+gtk+python thing happening with my own projects, as soon as time
allows. Is there resistance in the upper Python echelons to GTK
because of its LGPL licensing?

Reading Alex's Nutshell book, right off the bat he comments that "The
most popular Python GUI toolkit today is probably wxPython". But then
he goes on for 45 pages on Tkinter... Seems like he wanted to write
that chapter on wx instead...

WxWidgets, the last time I looked at it, seemed awfully like MS
Window's MFC. The licensing seemed vague at the time, and it looks
like wx contains an extra layer of GUI library, so I didn't spend any
real time on it. But, regardless, it seems to get good press among
python folk (I think I remember ESR noting how it was his GUI toolkit
of choice).

PyQt has had that issue (IIRC) about needing to pay for it for
commercial apps, so I can see how there might be resistance to it
being considered the "standard Python GUI toolkit".

So, it would seem to me that Tkinter *might* remain in Python proper,
but that I probably wouldn't see much effort put into it. Well, the
Python standard library docs tell a different story. There's stuff in
there about Tix, ScrolledText, turtle, and then the "other GUI
packages" doc page goes on about Python megawidgets (Tk-based) and
Tkinter3000 Widget Construction Kit (WCK). Wow. Looks like Tkinter is
still having serious support -- even though in that same doc at the
bottom notes, "PyGTK, PyQt, and wxPython, all have a modern look and
feel and far more widgets and better documentation than Tkinter."

So, that leaves me wondering, why is Tkinter still getting so much
focus in the Python standard library?

Maybe a better question is, how has Tk managed to keep beating up the
newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

Tk was there at the beginning unlike bindings to wxWidgets or QT so it
got all the standard library modules, too and they are still supported
not to break compatability.

 

[bramble]

First-mover advantage.

I don't know... As I meant to imply above, it's looking like Tkinter
will be playing its expected role in Py3k as the GUI toolkit of
choice. And from what I've seen of the Py3k effort, there's been
really excellent work on pulling out stuff that should be pulled out.
So, if it was *really* simply only first-mover advantage keeping it
there, I'd expect to see talk of removing it from the standard
library.

BTW, pulling Tkinter and related GUI stuff out of Py3k's standard
library wouldn't harm existing Tkinter users -- it would merely
require them to actually install it if they want it.

Maybe the key I'm missing is this: maybe GvR and company think that a
language absolutely should come off-the-shelf with GUI toolkit
bindings. So, given that, they feel they've gotta pick just one, and
they've already got Tkinter and it works, so that's that. Is that it?

 

[bramble]

BTW, pulling Tkinter and related GUI stuff out of Py3k's standard
library wouldn't harm existing Tkinter users -- it would merely
require them to actually install it if they want it.

Oops. I meant to put in there, after the "BTW,": "it seems to me
that".

 

[bramble]

and they are still supported
not to break compatability.

Hm. Ok. I can see that for the 2.x releases. But Py3k is all about
breaking compatibility, so, it would seem there's more to the story.

 

[Robert Kern]

Hm. Ok. I can see that for the 2.x releases. But Py3k is all about
breaking compatibility, so, it would seem there's more to the story.

Yes, compatibility is broken, strictly speaking; however, the goal is that the
majority of changes can be handled automatically using the 2to3 tool to convert
the source code. You can't really do that if you remove Tkinter entirely.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Diez B. Roggisch]

Maybe a better question is, how has Tk managed to keep beating up the

newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

There is no secret weapon. It's a question about dependencies, maintenance,
stability and supported platforms.

Using one of the other Toolkits would mean that an awful lot of libraries
need to be included as well - even nowadays, people complain about the size
of a python distribution.

Then something in the core libraries has to be actively & reliably
maintained to not endanger the overall release cycles.

Linked to that is the question of stability - not so much as "it doesn't
crash" but more on the lines of "it doesn't move so fast people cry for
newer versions all the time"

And last but not least is Tk available on a wide range of platforms, larger
than more or less every other toolkit. I know of a popular source control
software which vendor chose Tk for the same reason.

Diez

 

[Paul Boddie]

Maybe the key I'm missing is this: maybe GvR and company think that a
language absolutely should come off-the-shelf with GUI toolkit
bindings. So, given that, they feel they've gotta pick just one, and
they've already got Tkinter and it works, so that's that. Is that it?

Yes. Also, Tk isn't a particularly fast-moving target compared to some
of the other toolkits, so it's possible to not spend too much time
maintaining the bindings for it, I imagine. Otherwise, Tkinter might
have fallen out of the standard library by now.

Paul

 

[Carsten Haese]

But Py3k is all about breaking compatibility

That's a complete distortion of Python 3.0's mission. Python 3.0 breaks
backwards compatibility only where there exist good reasons to do so. As
Guido put it in a recent Python-3000 post, "Python 3000 is boldly
choosing to be backwards compatible, except in cases where a real
benefit can be obtained by being incompatible."

So, unless you can make a case that a real benefit can be obtained by
removing Tkinter, it'll stay.

 

[Kevin Walzer]

Maybe a better question is, how has Tk managed to keep beating up the
newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

Wouldn't license compatability be an issue? Tk's license is BSD-style,
which means it plays nice with both proprietary and open-source software
(as does Python's license). Aren't PyGtk and wxPython LGPL? And PyQt is
either GPL or proprietary.

 

[Terry Reedy]

| I don't know... As I meant to imply above, it's looking like Tkinter
| will be playing its expected role in Py3k as the GUI toolkit of
| choice. And from what I've seen of the Py3k effort, there's been
| really excellent work on pulling out stuff that should be pulled out.
| So, if it was *really* simply only first-mover advantage keeping it
| there, I'd expect to see talk of removing it from the standard
| library.

First, the 3.0a1 release put off modification of the stdlib. Second, Guido
wants to distribute a minimal development environment - Idle - and that is
written in TKinter. Third, I have not seen a formal proposal from the
authors of any other GUI toolkit that such replace TKinter or even
supplement it. There are disadvantages as well as advantages to having
one's work in the stdlib.

 

[jim-on-linux]

What is the backstory to why Python includes Tk bindings, as
opposed to some other set of bindings?

I've written a few little Tkinter-based apps, and it's nice and
simple. I like it well enough. That said though, I keep feeling the
gravitational pull toward GTK+. I've been meaning to get the whole
glade+gtk+python thing happening with my own projects, as soon as
time allows. Is there resistance in the upper Python echelons to
GTK because of its LGPL licensing?

Reading Alex's Nutshell book, right off the bat he comments that
"The most popular Python GUI toolkit today is probably wxPython".
But then he goes on for 45 pages on Tkinter... Seems like he wanted
to write that chapter on wx instead...

WxWidgets, the last time I looked at it, seemed awfully like MS
Window's MFC. The licensing seemed vague at the time, and it looks
like wx contains an extra layer of GUI library, so I didn't spend
any real time on it. But, regardless, it seems to get good press
among python folk (I think I remember ESR noting how it was his GUI
toolkit of choice).

PyQt has had that issue (IIRC) about needing to pay for it for
commercial apps, so I can see how there might be resistance to it
being considered the "standard Python GUI toolkit".

So, it would seem to me that Tkinter *might* remain in Python
proper, but that I probably wouldn't see much effort put into it.
Well, the Python standard library docs tell a different story.
There's stuff in there about Tix, ScrolledText, turtle, and then
the "other GUI packages" doc page goes on about Python megawidgets
(Tk-based) and Tkinter3000 Widget Construction Kit (WCK). Wow.
Looks like Tkinter is still having serious support -- even though
in that same doc at the bottom notes, "PyGTK, PyQt, and wxPython,
all have a modern look and feel and far more widgets and better
documentation than Tkinter."

So, that leaves me wondering, why is Tkinter still getting so much
focus in the Python standard library?

Maybe a better question is, how has Tk managed to keep beating up
the newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

Tkinter's secret weapon are pgmrs like me that would rather put
pressure on the Tk people to improve what already is working. Update
and improve Tk, change the look and feel of it, add features. Let me
spend my time programming not trying to make existing programs
compatible with the unknown. (Some change to who knows what.)

On the other hand, questions like yours are exactly what keeps the
pressure on the Tkinter people to upgrade. I think they got the
message with the recent announcement of some long awaited changes.


jim-on-linux
http://inqvista.com

 

[Chris Mellon]

What is the backstory to why Python includes Tk bindings, as opposed
to some other set of bindings?

I've written a few little Tkinter-based apps, and it's nice and
simple. I like it well enough. That said though, I keep feeling the
gravitational pull toward GTK+. I've been meaning to get the whole
glade+gtk+python thing happening with my own projects, as soon as time
allows. Is there resistance in the upper Python echelons to GTK
because of its LGPL licensing?

Reading Alex's Nutshell book, right off the bat he comments that "The
most popular Python GUI toolkit today is probably wxPython". But then
he goes on for 45 pages on Tkinter... Seems like he wanted to write
that chapter on wx instead...

WxWidgets, the last time I looked at it, seemed awfully like MS
Window's MFC. The licensing seemed vague at the time, and it looks
like wx contains an extra layer of GUI library, so I didn't spend any
real time on it. But, regardless, it seems to get good press among
python folk (I think I remember ESR noting how it was his GUI toolkit
of choice).

PyQt has had that issue (IIRC) about needing to pay for it for
commercial apps, so I can see how there might be resistance to it
being considered the "standard Python GUI toolkit".

So, it would seem to me that Tkinter *might* remain in Python proper,
but that I probably wouldn't see much effort put into it. Well, the
Python standard library docs tell a different story. There's stuff in
there about Tix, ScrolledText, turtle, and then the "other GUI
packages" doc page goes on about Python megawidgets (Tk-based) and
Tkinter3000 Widget Construction Kit (WCK). Wow. Looks like Tkinter is
still having serious support -- even though in that same doc at the
bottom notes, "PyGTK, PyQt, and wxPython, all have a modern look and
feel and far more widgets and better documentation than Tkinter."

So, that leaves me wondering, why is Tkinter still getting so much
focus in the Python standard library?

Maybe a better question is, how has Tk managed to keep beating up the
newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

Tk is stable, slow moving, highly portable, and liberally licensed.
It's not very good except for that, but those are very important
characteristics for something in the standard library. You'll note
that Tix and the various other Tk "expansion packs" aren't in the
stdlib.

wxPython is LGPL with a binary linking exception - there's no license
ambiguity there - but it develops far too fast to be in the stdlib.

PyQt is GPL or commercial only and I wouldn't consider that suitable
for a standard library package.

PyGtk has poor cross platform support, a very large footprint (the
largest of all these libraries) as well as a complicated runtime
environment. It's probably the closest to suitable for standard
library inclusion, but it doesn't have the binary linking exemption
that wxPython does (theres some question as to how needed that is for
Python code, though) and it's got no compelling API advantage over Tk.
If you want to trade the large footprint for the more advanced
toolkit, thats an option you have but I don't think it's a suitable
standard library decision.

 

[bramble]

Yes.

Ahh... Ok. Thanks, that explains it. At first, it hadn't ocurred to me
that anyone would want to provide a GUI toolkit binding along with a
popular general purpose programming language implementation. Moreover,
it *really* wouldn't occur to me that they'd also want to provide an
IDE (as Terry mentions in another reply). But then, I'm looking at
Python today, in 2007, at a time when Python has multiple high-quality
GUI toolkit bindings available, and when most editors and IDE's have
excellent Python support built-in.

Given that line of reasoning though, it seems odd to me that GvR and
Co. would still regard shipping those as part of Python proper as a
requirement for Py3k.

 

[bramble]

That's a complete distortion of Python 3.0's mission. Python 3.0 breaks
backwards compatibility only where there exist good reasons to do so. As
Guido put it in a recent Python-3000 post, "Python 3000 is boldly
choosing to be backwards compatible, except in cases where a real
benefit can be obtained by being incompatible."

So, unless you can make a case that a real benefit can be obtained by
removing Tkinter, it'll stay.

Well, it of course wouldn't break backward compatibility by simply
removing it from the standard library and providing it as an optional
extra set of modules.

 

[James Stroud]

Maybe a better question is, how has Tk managed to keep beating up the
newer, more modern, more featureful, better documented toolkits
encroaching on his territory? What's Tk's secret weapon?

On the OS vendor level, it may not be beating Tkinter. OSX 10.4 comes
out of the box (no action by the user required to install it) with
python 2.3.5 + wx 2.5.3.1:

mbi136-54 25% /usr/bin/python
Python 2.3.5 (#1, Aug 19 2006, 21:31:42)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
py> import wx
py> wx.__version__
'2.5.3.1'
py> ^D
mbi136-54 27% uname -v
Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007;
root:xnu-792.22.5~1/RELEASE_I386

Consider also that a similar setup with ubuntu is only an apt-get away.
And, if you know the proper incantations, is probably just as easy with
fedora.

Window$ of course...cousucksgh...Excuse me...doesn't get support for
anything like that from micr$oft, but I think its very easy with enthought.

So in some ways, Tkinter appears to be simply vestigial.

James

 

[Paul Boddie]

Ahh... Ok. Thanks, that explains it. At first, it hadn't ocurred to me
that anyone would want to provide a GUI toolkit binding along with a
popular general purpose programming language implementation. Moreover,
it *really* wouldn't occur to me that they'd also want to provide an
IDE (as Terry mentions in another reply). But then, I'm looking at
Python today, in 2007, at a time when Python has multiple high-quality
GUI toolkit bindings available, and when most editors and IDE's have
excellent Python support built-in.

Yes, and if you consider the situation about ten or more years ago, it
was rather different from now: Tk had been the most promising open
source cross-platform toolkit for a number of years (Qt wasn't open
source until 1998 and wasn't Free Software until 2000 [1]; Gtk+ was
only just getting started [2]; wxWindows, as it was then - and should
really still be - provided support for different backends, but on UNIX-
like platforms relied on legacy toolkits like Xt and Motif [3]), and
many languages offered Tk bindings in order to show their suitability
for GUI programming. Java was probably the first notable mainstream
language of the day to shun Tk, but even languages/runtimes like Limbo/
Inferno (which wasn't open source back then) provided a Tk-like
interface if not Tk itself, and I think a number of less well-known
languages of a certain age offer Tk bindings just as the standard
CPython distribution does.

Given that line of reasoning though, it seems odd to me that GvR and
Co. would still regard shipping those as part of Python proper as a
requirement for Py3k.

If they aren't broken then there's no need to fix them, even after the
controlled breakage involved in the making of Python 3000. ;-)

Paul

[1] http://trolltech.com/company/about/milestones
(note the difference between "open source" and the stricter Free
Software criteria)
[2] http://docs.gimp.org/en/gimp-introduction-history-early-days.html
[3] http://www.wxwidgets.org/about/history.htm

 

[bramble]

PyGtk has poor cross platform support, a very large footprint (the
largest of all these libraries) as well as a complicated runtime
environment.

What's complicated about it?

 

[Grant Edwards]

PyGtk has poor cross platform support, a very large footprint (the
largest of all these libraries)

It's larger than wxWidgets on top of Gtk?

as well as a complicated runtime environment. It's probably
the closest to suitable for standard library inclusion, but it
doesn't have the binary linking exemption that wxPython does
(theres some question as to how needed that is for Python
code, though) and it's got no compelling API advantage over
Tk.

I like the fact that it doesn't include a whole extra scripting
language interpreter along with it the way tkinter sucks in Tcl.