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

Josiah Carlson jcarlson at uci.edu
Thu May 11 08:37:49 CEST 2006


"Giovanni Bajo" <rasky at develer.com> wrote:
> It's sufficient to show that a library that uses native widget has to go
> through many hoops to implement any slightly non-standard feature. And
> causes the mental overhead which makes it unpythonic.

I would disagree.

The fact that it can be done, in spite of the fact that the underlying
controls do not offer such functionality, says quite a bit about
wxPython's wrapping of native controls.  The fact that /in this
particular case/ a few hoops need to be jumped through, is a bit of a
red herring; now that I've described how to get Qt-like behavior in
wxPython, what about getting a tree control in a ComboBox?  In the
wxPython case, it's already done...

Further, calling the composition of custom widgets to fit a desired
functionality "mental overhead" and "unpythonic", is a naive way of
saying "custom controls aren't worth making because you have to think to
make them".  Using your logic, making the Firefox Download Manager
entries would be too much "mental overhead" and would be "unpythonic" if
it were to be done in a Python application.  I call bollocks.


> Compare this with PyQt. You create a QComboBox (you wanted a combobox), and
> you can set a text and/or a pixmap for each item, using self.insertItem(px,
> txt).

So you are saying: because PyQt previously designed and implemented this
particular variant of a combobox (with images), it proves that going
non-native is better?  No, it just proves that this variant of the
ComboBox in PyQt was designed with this particular feature in mind.

Similarly, just because someone has spent the time to embed a
TreeControl in a dropdown for wxPython, doesn't necessarily mean that
wxPython is more flexible in this regard.


A slightly better question than what you originally asked for with both
PyQt, PyGtk, wxPython, PyGUI, etc., is how easy is it to customize
controls, mix/match controls, etc.?  I only have experience with
wxPython, but in my experience, it is trivial to create almost any
composite control that I can (and have) imagined (even a Firefox
Download Manager-like widget).


> Qt can export a much better, friendly and well-designed API because it
> doesn't rely on native widgets. It draws the widgets itself, so they always
> have the very same features for all the platforms that Qt supports. For
> instance, the other day I shrinked a horizontal scrollbar in the vertical
> direction (make it look "smaller"). It worked immediately for Windows, Mac
> and Linux. I don't think Windows can have a "smaller" scrollbar at all, for
> instance, at least not without adjusting its theme.

Having identical behavior on all platforms is wonderful, I'm very happy
for you and everyone else with a toolkit (programming language, etc.) that
does the same. For the rest of us who cannot use PyQt for one reason or
another (licensing...), we must rely on non-Qt tools, and as such, are
likely going to have to deal with wrapped native controls.  Yeah,
dealing with platform-specific crap isn't ideal, but it's not unique to
GUI toolkits, and it's certainly not a stranger to Python.


 - Josiah



More information about the Python-3000 mailing list