Greg Ewing <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > Also, it would require shipping a Python GTK binding, which would > > basically necessitate shipping GTK+ with Python. > > Keep in mind that PyGUI is still very much a work in progress. > My eventual goal is for each implementation to depend only on > what is provided natively by the platform. The use of the Gtk > implementation on Windows is only a stopgap measure until > something more native is available.
That does make me feel a bit better, but I think that people will have concerns about choosing a GUI library with such a limited number of widgets (I believe even tk+Tix has more than PyGUI at the moment). The current relative lack of richness in the PyGUI widget set is a con against its inclusion. From what I understand, the reason Tix was included with Python is because tk had a limited widget set. > > we may as well go whole hog and take wxPython; > > I'd be disappointed if something like wxPython were chosen > as the next "official" Python gui, for a lot of reasons -- > bloat, ugly and unpythonic API, non-native appearance and > behaviour, dubious quality of ports, etc. wxPython, generally speaking, uses the 'native' widgets on the platforms it is being used on. In Windows, that means MFC. On OSX, that means Carbon or Cocoa. On *nix, that could be GTK+ or X11/motif. Taking a wander through the wxWidgets and wxPython screenshots (http://wxwidgets.org/screensh.htm and http://wxpython.org/screenshots.php), they seem quite native-looking to me. Behavior-wise, that could be a function of the programmer of the application; not everyone reads Apple's (or MSFT's or Gnome's) design guidelines. If the quality of a particular port is lacking, that is, if it is buggy, make sure that the bugs are known so that they can get better. While the API does leave something to be desired, it is not terribly difficult to understand, but could certainly be made easier to understand with help. > > and it offers an "upgrade" path towards more "Pythonic" > > additions like Pythoncard, Wax, or even Dabo. > > I'm also not fond of the idea of putting yet more layers of > code over something that's already too bloated. There are certainly portions of wxPython that don't necessarily need to be there from an API perspective; wxPoint, wxString, etc., but at least in the case of wxPython, need to exist for the underlying wxWidgets implementation. It is unfortunate, but I doubt that the perhaps two dozen extraneous classes offer significant bloat compared to the 100+ widgets and their supporting events, items, handlers, etc. One of the reasons why I like wxPython, is because every widget I've ever wanted or needed to use, is already there. Sometimes the documentation is a bit terse, but it takes 5 minutes to look through the (extensive) demo and know almost precisely what to do. I should mention that a few months ago, an individual came into the wxPython-users mailing list and started talking about writing his own GUI toolkit, because though wxPython is considered among many to be 'the best Python GUI toolkit around', he also shared many of your and Bill's concerns and criticisms about wxPython. See the "cold shower request" thread started by Peter Damoc around November 7th last year. If I remember correctly, he ended up sticking with wxPython (and perhaps Dabo) because developing a new GUI toolkit would be a nontrivial amount of effort just to get to a fraction of the widget and functionality coverage of any one of the other toolkits (GTK, Qt, wxWidgets, Fox, etc.). Ultimately, the desire is to have a "Pythonic" GUI toolkit for Python, optimally included in the standard library. You and others are working to get PyGUI wrapping native controls to produce a Pythonic library from the ground up. That's great, that's wonderful, that's quite a bit of work (not the least of which being the result of platform-specific issues). The people working on PythonCard, Wax and Dabo had the same idea, though they started with wxPython as a base, because wxPython, generally speaking, abstracts away most of the platform-specific stuff (thus hopefully reducing the amount of work necessary). I haven't heard much about PythonCard and Wax development recently, but Dabo seems to be progressing at a pretty good speed. - Josiah _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
