[Python-3000] Requirements for a standard GUI library

[Terry Reedy]

"Travis E. Oliphant" <oliphant.travis at ieee.org> wrote in message 
news:446256F9.50507 at ieee.org...
> Not much different at all except in breadth.  I like the idea of PyGUI
> (it doesn't cover all backends, yet though).   Sorry I wasn't more
> clear.  The only thing I would wish different is to get rid of the PyGTK
> dependency.   I think PyGUI should be a wrapper directly on top of GNOME
> because the only reason not to go down to raw X11 is for look-and-feel.
>  Thus, PyGUI should go to the GNOME libraries and wrap them directly
> instead of using another Python layer that wraps it.  Then another PyGUI
> backend would wrap the KDE libraries directly for its look and feel (but
> the same PyGUI paradigm).
>
> In short, I don't like the chaining effect of wrapper on top of wrapper.
>  I want to make the connection to platform libraries as simple as
> possible.   Ultimately, I also think PyGUI should provide a simple
> look-and-feel of its own as well for situations where there is no
> "platform" look and feel (i.e. Unix users without either KDE or GNOME
> and just X11 or some other windowing environment).
>
> Such a thing would be a very useful addition to Python.   And make no
> mistake, I think PyGUI is going in the right direction.  So, three
> cheers for Greg...

My thoughts on PyGUI from reading the docs and some of the source:

First, it is actually three things, partially separable:

1. A Python-class-based application framework GUI: a fairly abstract layer.
2. An implementation design: generic classes overridden by specific toolkit 
classes.
3. A set of implementations: Cocoa and GTK so far.

Second, it needs some additions before prime time (stdlib inclusion):

1. Greg included the few widgets he needs; others want others and more.  If 
the drawing primitives (line,box, fill, image) in the current design are 
adequate, it should not be terribly difficult to add more, perhaps in a 
separate module, perhaps supervised by someone else.  I wonder whether the 
add-on module for Tkinter could be modified and somewhat reused.

2. There are roughly 30 generic modules (most very small) and 30 specific 
implementation modules (for each implementation, but only one set used at a 
time).  This makes for a lots of imports.  I wonder if startup would be 
noticeably faster if these were consolidated to two files/modules.  (I 
haven't gotten PyGUI up on my WinXP machine yet to test how long it takes). 
My idea is that they could be kept separate for development, if desired, 
and then consolidated by a rerunnable script.  There will also be a lot of 
entiries in sys.modules, making it harder to list and search by eye.

3. More implementations are needed, not necessarily by Greg.  Indeed, a 
test of the documentation, both in the doc and module docstrings and 
comments, is that someone else can do a port.  An obvious one to add is 
native Windows, without going thru GTK.

Less obvious might be SDL (Simple Directmedia Library).  It apparently runs 
on several platforms beyond the main ones, so a port would put the GUI on 
most of the platforms that Python runs on.  On some systems, SDL uses any 
of multiple video/graphics drivers.  So on Windows, it can use either the 
standard Windows GDI interface or full-screen DirectDraw.  On *nix, it can 
use any of about 10 different graphics drivers, X11 being only one, so it 
is not at all restricted to systems using X11.  The current Python wrapping 
is part of Pygame (done with Swig, I presume).  There has been some 
discussion by Pygame people of replacing the current wrapping with more 
direct calls using ctypes.

Terry Jan Reedy