[Interest] QAbstractItemModel and lazy loading

[Adam Light]

Hi Jan

Thanks for your reply. I've responded to a few things inline below.

On Mon, May 14, 2012 at 7:59 AM, Jan Kundrát <jkt at flaska.net> wrote:

>
> I'd strongly encourage to check your model using ModelTest [1]. The
> trouble with Qt models is that any error you make will usually result in
> subtle errors or segfaults at a later time.
>

I'm actually already doing this. It was very useful when developing my
model but currently it is not flagging any issues.



> Lazy loading can still work, even in this scenario. You're right that
> there seems to be a slight asymmetry in the MVC API when dynamically
> updating the model; unlike the hasChildren() method, there's nothing
> like childrenArrived() signal and you really have to emulate that by
> calling beginInsertRows etc. However, these items that you somehow have
> to manufacture can easily be created by your model without actually
> fetching their real data; that can be deferred to the time the model
> gets aksed for them (through data() or any other relevant function in
> your scenario).
>
>
Ok, it's good to know that I'm not missing something here. Unfortunately,
in my situation, discovering how many new items there might be is the slow
part because this involves traversing several linked lists which could have
thousands of members. My model is simply storing a pointer to each object
it contains, so getting the data is fast but traversing the list can be
slow.

It does not look like there is a way to "fake out" the model by
calling beginInsertRows telling it that I will insert 0 rows. Otherwise, I
think I'd need to insert the correct number of rows, and if I'm going to do
that then there is no point to lazy loading in my situation.

Your suggestion of returning true from hasChildren() would work but I was
hoping to avoid the confusing the user. The data that I am displaying with
this model/view combo is a tree structure of in memory objects of different
types, analogous to a disk file system with directories and different file
types.

You are right that creating a model that observes the internal state of the
application is very tricky. My approach has been to avoid duplicating as
much of the data as possible. Therefore, each index in my model is
associated with an Item class I wrote which primarily is used to store a
pointer to the actual object and a flag for the type of object. My model's
data() method then gets the pointer to the real item and, depending on its
type, is able to call my application's internal routines to get things like
the name, etc. The real problem is that the pointers I am storing are not
to QObject based classes, so I have to go to great lengths to prevent
dereferencing these pointers once they no longer exist.

I think that if we were to rewrite the application now we would store our
data in a very different way, but the application itself is 20 years old
and we worry that rewriting the way that the internal data is stored would
have plenty of unintended consequences.

Thanks for your help
Adam Light
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120514/64c2bca9/attachment.html>