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

[Jim Jewett]

On 5/9/06, Giovanni Bajo <rasky at develer.com> wrote:
> Jim Jewett <jimjjewett at gmail.com> wrote:

> > 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.)

> Does it?

> >>> from qt import *
> >>> app = QApplication([])
> >>> QMessageBox.question(None, "Confirmation", "Are you sure you want to
> exit?", QMessageBox.Yes, QMessageBox.No)
> [ dialog popups ]
> 3
> >>> QMessageBox.Yes, QMessageBox.No
> (3, 4)

You do realize that you just returned the integer 4, when you wanted
something False?  That is mental overhead.


> I don't agree with much of what you propose basically because I think it's
> hopeless to create a wrapper API above all the toolkits. There are far too many
> "details" which are different (just thinking of events, application event
> loops, signals/slots, HW accelerated painting primitives, multithreading
> dispatching).

So don't think about them.

Events (or slots, or signals) which are internal to the GUI do not
need to be exposed.
When it is needed, translating between from a signal to an event or an
event to a slot may not be the most graceful solution, but it will
work.

Why should the application writer have to specify hardware
acceleration?  If the wrapper library can't provide reasonable
defaults, then just don't use it.

-jJ