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

Giovanni Bajo rasky at develer.com
Wed May 10 03:37:25 CEST 2006


Talin <talin at acm.org> wrote:

>> 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). I dare anyone to
>> develop such an API so that it's production-ready (which is *not* a
>> Yes/No dialog) within the Py3k time constraint. I reckon that this
>> is pratically unfeasable (and, say what, totally useless).
>
> Java did it, so it can't be all *that* hard :)

Sorry, I don't know anything about Java. But didn't they take a couple of
iterations (= several years) before getting to the right point? I saw late Java
applications looking native enough, but I remember the first ones with that
horrible non-native GUI (SWING maybe?), and I remember screams of Javas
co-workers when trying to do something serious with it.

But, if Java *really* did it, let's *copy* it. My point is exactly that: Qt
*did* it, so let's use it. wxWidgets does *exactly* what you want: it's a
common abstraction over different native toolkit libraries. wxPython is very
widespread and accepted by the community. Why oh why redesigning something from
scratch.

> The main challenge is choosing the right level of abstraction.
> You don't want to be creating code that does different things
> on different platforms; You want to let the platform handle those
> details for you. OK, so menus behave differently on Win32 vs.
> OS X. So what? You shouldn't be handling individual mouse clicks
> at that level anyway.
>
> Similarly, it would be nightmarishly difficult to try and
> re-create the color chooser dialog on OS X, so why bother? Just
> use the one provided by the OS. (Unless you are using .Net,
> in which case you probably *want* to replace the color dialog :)


You probably know that Qt does exactly what you say (use native menus on Mac OS
X, and native color picker on all operating system), and it's still thousands
and thousands of lines of well-designed code.

Another issue (which by itself is going to get headaches to any GUI designed)
is how many native widgets can be used and how many needs to be redone. This is
a very delicate issue: in my experience, the solution of wxWidgets of going
totally native (that is, being just a wrapper around native widgets) is
unfortunate, because it coerces the programmer to use the lower common subset
of features across all platforms, to be consistent. This is why wxWidgets
reference manual is filled with "this works on Windows only, this works on Mac
only, this works with GTK only". OTOH, Qt decided to redo all the widgets from
scratch (but not the common dialogs of course), and then even reproduce the
native look & feel from scratch (hell, it even follow the user's custom theme
selection under XP). It's the hard, longest way, but it's the one that pays
most. Show me a combo-box with selects among items with both text and a bitmap,
done with wxPython, on all platforms.

Giovanni Bajo



More information about the Python-3000 mailing list