Scripting and Gnome and KDE

[Mitch Chapman]

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

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

--
Mitch Chapman
chapman at bioreason.com