[Eric] Bugs in latest eric4 snapshot

[Jürgen Urner]

Andreas Pakulat schrieb:
> On 05.04.07 00:03:18, Jürgen Urner wrote:
>   
>> Andreas Pakulat schrieb:
>>     
>>> Model indices are not persistent across application runs, but the Qt
>>> views do cache model indices that they retrieve from the model. As I
>>> said above, if you use internalPointer in python you need to make sure
>>> to keep a reference to the object yourself, i.e. in a list or dict.
>>> Thats why I tend to use internalId and keep a dict of id->object in the
>>> model.
>>>
>>>       
>> How can you know when Qt decides to reuse some memory?
>>     
>
> Huh, Qt doesn't decide to reuse any memory. Thats something that your OS
> will decide.
>
>   
>> Quote from QModelIndex docs:
>>
>>     
>>>> Model indexes can become invalid over time so they should be used
>>>> immediately and then discarded. If you need to keep a model index
>>>> over time use a QPersistentModelIndex <qpersistentmodelindex.html>.
>>>>         
>
> You quoted that already, nevertheless you're model should store any
> QModelIndex anyway, index-creation is cheap (or should be). The view
> however can (and all Qt views do) cache QModelIndex values that they've
> obtained from the model, this way they avoid calling index() millions of
> times just to display a 10x10 grid in a tableview. This however is an
> implementation detail of those views that nobody should rely or care
> about and actually there's quite some effort involved with keeping the
> cache up-to-date (also this cache is a reason why the Qt views can
> easily find bugs in your model)
>
>   
>> ...and even QPersistentModelIndex <qpersistentmodelindex.html> will become 
>> invalid if the index
>> is no longer reachable.
>>     
>
> I haven't looked at QPersistentModelIndex at all, so I can't really
> comment. But my understanding is that it should be possible to store
> this one away (in memory, on disk, wherever) and later on retrieve it
> and use it again.
>
> Anyway, I don't quite understand what you wanted to point at? The
> problematic code in eric4 does something like
>
> index = sourceModel.index(row,col)
> item = sourceModel.item(index)
>
> which is defined to be perfectly ok, i.e. the model can expect to get a
> proper index with a proper internalPointer or internalId, depending on
> which createIndex() overload it used. If an index turns out to be not
> invalid _and_ not have a proper id/pointer then the caller is doing
> something wrong. In the eric4 case I'm not sure yet, wether its the view
> or the filter model, because I haven't looked at the rest of the code
> yet...
>
> Andreas
>
>   

Was a bit tired yesterday, sorry and didn't look at the sources.
I had problems with QAbstractItemModel wich reminds me
of these. But its quite some time now and I am doing this
mostly from memory.

In BrowserModel  a mapping is maintaned index.internalId --> BrowserItem.
In cretaeIndex() a reference to the parent item is attatched to an
index and later retrieved in calls to self.item_dict[index.internalId()]
The (Python) id or an item is mapped to items and, if I understand it right,
the item is retrieved later by its (Qt | Python ?) id.

client calls model.index(row,col)
    atatch pointer to parent python object to
    index and return index

Qt calls model.parent() and maybe queries other indices
    do something with pointer(s)

client calls model.item(index)
    do something with pointer


Somewhere in between these calls the pointer may get lost
and you may access an arbitrary memory location or get an index error.
I guess all comes down to the interpretation of the word "emidiate" in
"indices are intended for emidiate use". I may be wrong, but that's how I
figured it out for myself.


Jürgen