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

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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?

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]

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]

What's complicated about it?

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]

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]

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.

You've got to admit that Tk "just works", although as a result
it looks ugly and foreign on all platforms.

 

[Chris Mellon]

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.

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]

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.

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]

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.

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".