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

[Giovanni Bajo]

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.


No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead?
Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember
different APIs from the Yes/No case, if you're going to use a specialized
version returning just a boolean.

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

??? Events, slots and signals are all public parts of a GUI API.

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

No, it won't. Events and signals are pretty different concepts. If you're not
making a difference between them, you're generalizing too much and losing
power. Anyway, it's not *me* that it's saying so. I'm just an average
programmer which wasted far too many hours working with unreasonable, broken,
incomplete, over-generalized, over-simplified, slow GUI APIs. Look at the API
of Qt: it is a successful, production-ready toolkit for a reason.

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


I was just trying to say that designing something like QPainter, with a common
API which totally abstracts from the OS details but still allows hardware
acceleration on most platforms (GDI+ on Windows, for instance) is very very
complex (and it went through several revisions and refinements). I don't expect
anyone to come out with a better API on their first try. Of course, they could
just copy it. But then, why don't adopt it?

Giovanni Bajo