[Python-3000] GUI -- an API, not a toolkit

[Jim Jewett]

On 5/9/06, Ivan Krstic <krstic at fas.harvard.edu> wrote:
> Jim Jewett wrote:
> > By spitting out html and javascript, rather than draw/paint commands.

> I was afraid you were going to say that. I, for one, welcome our new
> AJAX overlords, but to want to task a general GUI toolkit with producing
> HTML and Javascript, running a HTTP server, and automagically dealing
> with all the server-side logic seems a bit like a really bad joke.

Exactly!

And hauling in a widget set larger than python so that my command line
programs could pop up windows with buttons with properly rounded
corners and arbitrary shading seems just as foolish.



    It is reasonable to have a pythonic UI API that says "create a dialog".

    Bill Janssen nominated Greg's PyGUI as a good candidate.


    Stop here.  This was almost the entire extent of the preference for PyGUI.



It is reasonable to ship with a default implementation of that API, in
case users or developers don't want to bother downloading a
better/fuller implementation.

Greg does provide one, for much of PyGUI.  He uses an underlying
cross-platform GUI to reduce his own maintenance nightmares.  If
someone else wanted to provide an alternative implementation using
native controls for MS Windows (or BeOS, for that matter), I doubt he
would object.  It might even make sense to use that replacement as the
default distribution on that platform.  Greg hasn't done this yet,
because it hasn't been worth his time.

Of course, no one has done that for any of the other frameworks
either, despite much greater manpower.  Switching from wxWidgets to Qt
isn't just a matter of installing the new library; you also have to
change huge portions of your own code to handle the different calling
conventions.

It is unreasonable to pretend that anything shipped with the standard
library could ever be complete and up-to-date for native
look-and-feel; python releases do not march in lockstep with OS
releases.

It is unreasonable to expect that Gnome or KDE partisans will suddenly
switch to whatever becomes the default.  It is not unreasonable to
expect them to write lightweight wrappers, so that users could replace
the default implementation with pyGTk or wax.

Replacing the full (and odd, for python code) Tkinter interface that
we have today would be a fairly large undertaking, so no one has. 
Replacing the basic UI API shouldn't be.  (So I'm inclined to wonder
if PyGUI is already too heavy.)

Applications using the Python UI API wouldn't get all the features
available from, say, wxWindows, but they would get some of the
benefits, such as a look and feel consistent with whichever particular
toolkit the *user* chose.

More importantly, the applications would continue to run even if the
user later switched to a different GUI provider.  Users could choose
to try out the latest GTk, or a retro-mac-classic scheme, or an
over-the-web AJAX scheme; the application would not need to care,
except to the extent that it relied on non-standard widget extensions.

Most importantly, the application programmer wouldn't need to care. 
Right now, if you want to create a python application with a GUI, you
need to learn python, plus the GUI framework, plus the python
bindings.

To just create a preference picker and an OK/Cancel dialog -- the
mental overhead really shouldn't be much worse than using a single
python module from the standard library.  (And yes, this rules out
using pretty much any existing framework as the API.)

-jJ