[PyQt] Looking for complex tree view example

David Boddie dboddie at trolltech.com
Fri Apr 18 12:41:41 BST 2008


On Fri Apr 18 08:29:23 BST 2008, Aaron Digulla wrote:
> Quoting David Boddie <david at boddie.org.uk>:
> 
> > You could port the C++ Editable Tree Model example from the Qt package,
> > but that might not be dynamic enough for your purposes.
> >
> > Another example of the model/view classes in Python is the PyPI Browser
> > application I started writing almost two years ago(!):
> >
> >   http://pypi.python.org/pypi/PyPI-Browser/1.5
> 
> I'll have a look at both.

And the ModelTest example/project (ported from the Trolltech Labs project)
included in the PyQt4 distribution might be useful for testing purposes.

> > There should be lots of other complex models out there written in Python,
> > especially in the scientific computing and visualisation domain.
> 
> "Should" is the keyword here. Googling for "pyqt QAbstractItemModel  
> class def __init__" yields 4 pages of results of which three are  
> relevant. koders.com returns 16 examples.

I was thinking of projects like OpenAlea when I wrote about other examples,
though perhaps the trees used there aren't all that dynamic.

  http://openalea.gforge.inria.fr/dokuwiki/doku.php

There are probably a lot more C++ ones out there, of course, but I would
imagine that almost every programming/scientific project uses tree views
in some form. It's just a matter of how complex the models in use are.

> I feel that this is a no-go area: There is little information how to  
> create a real-world tree model with more than one column and it seems  
> that few people have dared to venture into this. Those examples that  
> do exist are very limited. They either just display data or allow  
> inline editing. I just found a single example which allows to move  
> nodes around, I've never seen drag'n'drop node moving anywhere.

Take a look at the Puzzle example for some basic drag and drop handling:

  http://doc.trolltech.com/4.4-snapshot/itemviews-puzzle.html

I agree that it's not very sophisticated, but it's important to cover the
basic principles in examples before showing more real-world techniques,
though there's definitely room for those as well.

> Okay, I feel I need to vent some frustration. Take the following with  
> a grain of salt and remember that someone who criticizes you cares  
> about you.

That's OK, I'm sure the feelings are mutual. ;-)

> My own experiments with the tree model resulted in a lot of spurious  
> crashes because of memory issues. I'd really prefer if the PyQt  
> developers would stop insisting that I have to get the memory model  
> right or my application will crash. I mean, even if I make a mistake  
> in my code, it *might* run for a while and then suddenly crash at a  
> completely different place! That's not the "Python way". That's  
> exactly why I stopped using C/C++ ten years ago.

I think that many of these are the result of the fragility of the underlying
API in combination with the difficulties in integrating it with a language
implementation with its own garbage collection strategies.

> I mean, I'm a seasoned programmer, I've written my own OS and text  
> editor, I understand how memory allocation works and how it plays with  
> virtual memory, I've written libraries which can be used from Python,  
> etc. and even I can't get it right with PyQt! Don't take this as an  
> insult but for me, it feels that PyQt is *designed* to make it easier  
> to produce buggy code than stable code. Just look at the amount of  
> mails on this list with people who have memory issues!

Are most of those issues related to item views?

> And what bugs me most is that many of these issues could be prevented  
> with just small changes in the PyQt layer (like saving a pointer to  
> the model when you call setModel()). It feels like PyQt is 95% good,  
> so the bad 5% hurt even more because it almost perfect!

I guess some reference counting could be done to protect Python, but nothing
will protect you from problems that occur at the C++ level, and there's a
good chance some problems will manifest themselves there. You might get the
badness down to 1% - is that low enough?

> If all else fails, there should at least be a "safe net" version of  
> PyQt which tracks all Qt objects created and prints warnings with  
> stack traces when they leak or might be deleted before both sides are  
> done with them.

This sounds good in principle, but may be difficult to do in a generic way.
The ownership of objects in parts of the Qt API is only informally defined,
so it might require further annotations to be added to the SIP files to
describe this.

> It would also help if PyQt could print complete stack traces like when  
> a python callback is invoked from Qt like in Python (A) -> Qt ->  
> Python (B): The stack trace will only show the B portion, so I have no  
> idea what A might be.

These ideas sound great but, again, difficult to implement. I don't know
enough about the internals of Python to say if this is possible - maybe you
have enough experience to work through the issues and produce a patch.

David
-- 
David Boddie
Lead Technical Writer, Trolltech ASA


More information about the PyQt mailing list