gui toolkits: the real story? (Tkinter, PyGTK, etc.)
bramble
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
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
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
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
> 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.
--
Carsten Haese
http://informixdb.sourceforge.net
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.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Terry Reedy
"bramble" <cadet....@gmail.com> wrote in message
news:1191293650.3...@n39g2000hsh.googlegroups.com...
| 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
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
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
> On 2 Okt, 04:54, bramble <cadet.bram...@gmail.com> wrote:
>
> > 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.
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
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.
--
Grant Edwards grante Yow! I'm encased in the
at lining of a pure pork
visi.com sausage!!
"Martin v. Löwis"
> 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?
The trick is very simple. Tkinter just *doesn't* get much focus. Very
few of the core developers actively work on it; I do so only once
every two years or so to merge all the patches that get contributed.
Regards,
Martin
Chris Mellon
> On 2007-10-02, Chris Mellon <ark...@gmail.com> wrote:
>
> > 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?
>
No, but it's larger than wx on top of the native API, so when you
average it across all platforms it's quite a bit larger.
Chris Mellon
There's an enormous amount of dependencies and runtime configuration,
such as finding theme engines and handling preferences. There's
solutions for managing all of that of course, but it's still much more
overhead than dirt-simple Tk.
Grant Edwards
> On 10/2/07, Grant Edwards <gra...@visi.com> wrote:
>> On 2007-10-02, Chris Mellon <ark...@gmail.com> wrote:
>>
>> > 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?
>
> No, but it's larger than wx on top of the native API,
A moot point for X11.
> so when you average it across all platforms it's quite a bit
> larger.
I guess that's one of the costs of portability.
--
Grant Edwards grante Yow! CHUBBY CHECKER just
at had a CHICKEN SANDWICH in
visi.com downtown DULUTH!
Grant Edwards
You've got to admit that Tk "just works", although as a result
it looks ugly and foreign on all platforms.
--
Grant Edwards grante Yow! So this is what it
at feels like to be potato
visi.com salad
Chris Mellon
> On 2007-10-03, Chris Mellon <ark...@gmail.com> wrote:
> > On 10/2/07, Grant Edwards <gra...@visi.com> wrote:
> >> On 2007-10-02, Chris Mellon <ark...@gmail.com> wrote:
> >>
> >> > 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?
> >
> > No, but it's larger than wx on top of the native API,
>
> A moot point for X11.
wxWidgets actually does have a raw X11 implementation, although nobody
uses it so it's not well maintained. And since X11 is hardly the only
platform that anyone cares about, evaluating a potential addition to
the standard library across *all* platforms is important.
>
> > so when you average it across all platforms it's quite a bit
> > larger.
>
> I guess that's one of the costs of portability.
>
Eh? The point is that wxWidgets, the more portable toolkit, is
*smaller* than Gtk. It's not really related to portability as much as
design considerations. Gtk is designed and intended to be used as a
system library, in conjunction with many other system libraries and
lots of system-level configuration. It was never written with the goal
of being an application-level toolkit.
bramble
> On 10/3/07, Grant Edwards <gra...@visi.com> wrote:
>
> > > On 10/2/07, Grant Edwards <gra...@visi.com> wrote:
>
> > >> > 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?
>
> > > No, but it's larger than wx on top of the native API,
>
> > A moot point for X11.
>
> wxWidgets actually does have a raw X11 implementation,
Wait though. If I want to use wxPython, my python code calls wxWidgets
code which calls gtk. So, it would seem simpler to remove 1 layer and
just call the gtk code directly via PyGTK.
>
> > > so when you average it across all platforms it's quite a bit
> > > larger.
>
> > I guess that's one of the costs of portability.
>
> Eh? The point is that wxWidgets, the more portable toolkit, is
> *smaller* than Gtk. It's not really related to portability as much as
> design considerations.
Isn't wxWidgets smaller that GTK+ simply because it's a wrapper and
doesn't do its own drawing?
Chris Mellon
> On Oct 3, 1:39 pm, "Chris Mellon" <arka...@gmail.com> wrote:
> > On 10/3/07, Grant Edwards <gra...@visi.com> wrote:
> >
> > > On 2007-10-03, Chris Mellon <arka...@gmail.com> wrote:
> > > > On 10/2/07, Grant Edwards <gra...@visi.com> wrote:
> > > >> On 2007-10-02, Chris Mellon <arka...@gmail.com> wrote:
> >
> > > >> > 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?
> >
> > > > No, but it's larger than wx on top of the native API,
> >
> > > A moot point for X11.
> >
> > wxWidgets actually does have a raw X11 implementation,
>
> Wait though. If I want to use wxPython, my python code calls wxWidgets
> code which calls gtk. So, it would seem simpler to remove 1 layer and
> just call the gtk code directly via PyGTK.
>
By the same argument, you could say that Gtk just calls xlib, so why
not write against xlib directly? More direct is not always simpler.
But the real reason, of course, is that wxWidgets is a platform
abstraction API, and Gtk isn't.
Anyway, this discussion isn't about the relative merits of wxWidgets
and PyGtk in general, but specifically for inclusion in the standard
library.
> >
> > > > so when you average it across all platforms it's quite a bit
> > > > larger.
> >
> > > I guess that's one of the costs of portability.
> >
> > Eh? The point is that wxWidgets, the more portable toolkit, is
> > *smaller* than Gtk. It's not really related to portability as much as
> > design considerations.
>
> Isn't wxWidgets smaller that GTK+ simply because it's a wrapper and
> doesn't do its own drawing?
>
Not really, no. Qt also does all of its own drawing and is a fraction
of the size of Gtk. The amount of code thats responsible for drawing
is minuscule.
Lawrence D'Oliveiro
> You've got to admit that Tk "just works", although as a result
> it looks ugly and foreign on all platforms.
Sort of a "pidgin GUI". :)