[Python-3000] GUI -- an API, not a toolkit (original) (raw)

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.

More information about the Python-3000 mailing list