Scripting and Gnome and KDE
chapman at bioreason.com
Mon Apr 17 13:00:38 EDT 2000
Boudewijn Rempt wrote:
> Andrew Dalke <dalke at acm.org> wrote:
> > Even though it says "The result is a great environment for rapid
> > development of GUI-based applications." ?
> Yes - the article didn't make clear what was so great, but it did point
> out a lot of problems (lack of documentation, inconsistent API's, bugs).
> > I used to work at Bioreason, though I wasn't involved in the GUI
> > development. They are pretty happy about PyGTK. The idea of the
> > DDJ article was to point out how to take advantage of the toolkit,
> > based on finding out what doesn't work.
That's exactly right. It's fairly easy to get started with pygtk,
but some things about the toolkit are difficult to discover. We wanted
to show how to do the difficult (i.e. obscure) things, in order to
make them easy. The article introduction should have made that more
> Very honest, but it doesn't make me all that eager ;-).
> > You could write a similarly bleak picture of any toolkit.
In fact, I'd considered trying to write a similar article about PyQt
and PyKDE. But that article would have been even bleaker, because
the process of discovery w. PyQt is still difficult for me. I've
had a few recurring problems. Maybe this would be a good place to
ask for enlightenment :) I'll start w. the two biggies:
o The Qt C++ interfaces include many overloaded functions.
Is there a consistent pattern for determining which of
these is implemented by the Python binding? Or must
you look at the source code for the Python bindings?
o In many cases, if I make a wrong guess as to which
overloaded method is implemented by the binding, I get
a segmentation fault or (slightly better) a traceback
indicating an incorrect argument type. Is there an easy
way to work backwards from a segmentation fault to
the correct usage for a PyQT widget?
> Absolutely, but I don't know that an essay on the problems is exactly
> the right way of introducing the toolkit.
That's probably true. Given the goal of showing how to do non-obvious
things with a toolkit, what changes would you recommend?
If I understand your comments, it would have been better to simply
say, "Here's how you do X," rather than to explain "Here's *why* you
do it this way". I have one reservation with such an approach:
it tells the reader how to solve a specific problem, but
doesn't provide a general method for discovering how to use other
parts of the toolkit.
Hoping that made some sense...
chapman at bioreason.com
More information about the Python-list