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

[Chris Mellon]

On 10/3/07, bramble <cadet.bramble at gmail.com> wrote:
> On Oct 3, 1:39 pm, "Chris Mellon" <arka... at gmail.com> wrote:
> > On 10/3/07, Grant Edwards <gra... at visi.com> wrote:
> >
> > > On 2007-10-03, Chris Mellon <arka... at gmail.com> wrote:
> > > > On 10/2/07, Grant Edwards <gra... at visi.com> wrote:
> > > >> On 2007-10-02, Chris Mellon <arka... at 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.

> --
> http://mail.python.org/mailman/listinfo/python-list
>