On 10/3/07, bramble <[EMAIL PROTECTED]> wrote: > On Oct 3, 1:39 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > On 10/3/07, Grant Edwards <[EMAIL PROTECTED]> wrote: > > > > > On 2007-10-03, Chris Mellon <[EMAIL PROTECTED]> wrote: > > > > On 10/2/07, Grant Edwards <[EMAIL PROTECTED]> wrote: > > > >> On 2007-10-02, Chris Mellon <[EMAIL PROTECTED]> 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 > -- http://mail.python.org/mailman/listinfo/python-list
