[Python-3000] Add a standard GUI system

[Josiah Carlson]

Greg Ewing <greg.ewing at canterbury.ac.nz> 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