Scripting and Gnome and KDE

[Boudewijn Rempt]

Mitch Chapman <chapman at bioreason.com> wrote:

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

Well, I've been working with PyQt and PyKDE for about year now, and I must
say I've never had that problem. Most overloaded functions differ in the
number of arguments, making it simple to determine which one is chosen;
as for the functions where the type of arguments is the only difference,
the bindings check the type of the arguments and choose the right
function:

The docs:

The QListViewItem class implements a list view item. More... 

Public Members

  * QListViewItem ( QListView * parent, const char *, const char * = 0,
const char * = 0, const char * = 0, const char * = 0, const char * = 0,
const char * = 0, const char * = 0 )  
  * QListViewItem ( QListViewItem * parent, const char *, const char * = 0,
const char * = 0, const char * = 0, const char * = 0, const char * = 0,
const char * = 0, const char * = 0 )  

Python code:
  listview=QListView(parent...)
  item1=QListViewItem(listview, "aaa")
	item2=QListViewItem(item1, "bbb")

Complete working example at:

  http://www.valdyas.org/python/overload.py

So the overloading problem doesn't exist at all ;-). No wonder I
hadn't noticed it. I wonder, how does wxPython handle this?

I haven't had many segfaults - mostly when trying out new features
in beta releases. 

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

Well, I'm not sure I saw any really non-obvious things - a treeview
isn't that spectacular nowadays, and neither is layout management.
(Although I must admit that I'd never thought that I would have to 
manually add scrolling to a treeview - that was very non-obvious to
me.)

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

No, not exactly: what I look for in an introductory article is the
advantages of an approach. For instance, 'this toolkit has a really
easy and unique canvas', or 'writing a webbrowser in this toolkit takes
just 100 lines with toolbar and all', or 'this toolkit supports unicode
through-and-through' - showing off the really unique and interesting
things.

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

I agree that that's useful. I spend a lot of time helping people
starting out with PyQt and PyKDE, showing them how to translate
the C++ documentation to Python. It's not difficult, just a mental
search-and-replace, but it's something one has to learn.

Besides, toolkits are different enough that migrating from one to
another often demands a complete new way of thinking: that's something
the article in Dr Dobbs did show: tkInter is one way of working,
PyQt another, but PyGTK is completely different once again. That's
an important insight, I feel.

-- 

Boudewijn Rempt  | http://www.valdyas.org