On 5/24/06, Andreas Pakulat <[EMAIL PROTECTED]> wrote:
On 24.05.06 16:39:28, Allen Bierbaum wrote:
[...]

> make things limp along.   I am currently  funneling all index lookups
> through a manually maintained map from int id's to python objects.  Is
> this how other people are also working with QT4 models?

Oh, you already found the "right" way...

> I was surprised that there was no way (that I know of) to attach a
> python object to a QModelIndex.  It seems from the QT documentation
> that this is the intent of how indexes are to be used in C++, but
> there is no corresponding way to do this in Python.

I can imagine that using id's and a dict is much safer. The
pointer-thing needs a cast and that cast can go wrong. Maybe it's also
just not possible.

> I think it could be implemented by casting from PyObject* to void*
> behind the scenes and passing through to the existing
> internalPointer() C++ interface.  This would make working in Python
> much easier while still preserving the intent of the QModelIndex
> interface.

I don't see why using internalPointer is easier than using internalId.
IMHO it doesn't matter much wether you do

item = static_cast<TreeItem*>(index.internalPointer())
or
item = self.obj_dict[index.internalId()]

One reason I am running into in my current code is that once you have
a map of id to objects there is no good way to know when to clear out
the map and thus release the references to the objects.

The other "problem" I have run into (and this is not unique to Python)
is that the QT data model requires bi-directional references in the
tree (parents need to know children, and children need to know
parents).   Many of the tree models that I need to view only have the
parents knowing the children and don't have the opposite direction.

Thanks for the pointers, I will take a fresh look at this code tomorrow.

-Allen

I guess the latter might also be faster, because there's no need to
interface with C.

Andreas

--
You learn to write as if to someone else because NEXT YEAR YOU WILL BE
"SOMEONE ELSE."

_______________________________________________
PyKDE mailing list    [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


_______________________________________________
PyKDE mailing list    [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

Reply via email to