[Qt-qml] Dummy model for QList<QObject*> model

[Cornelius Hald]

On Wed, 2010-09-15 at 05:53 +0200, michael.brasser at nokia.com wrote:
> On 15/09/2010, at 12:32 AM, ext Cornelius Hald wrote:
> > On Tue, 2010-09-14 at 16:10 +0200, Stephen Kelly wrote:
> >> Cornelius Hald wrote:
> >> 
> >>> Thanks! qmlRegisterType() helped with my own model (derived from
> >>> QAbstractListModel). With QObjectListModel I'm still having a problem,
> >>> because I don't understand how the roles are defined. From looking at
> >>> the code and the comments it looks like only one role with the name
> >>> "object" is defined. But then, how should I use it in QML?
> >> 
> >> Define Q_PROPERTIES and access them on the object.
> >> 
> >> delegate : Text { text: model.object.someProp; height : 20 }
> >> 
> >> I wrote something similar before but used the term 'data' instead of 
> >> 'object', so I used model.data.someProp.
> >> 
> >> http://steveire.wordpress.com/2010/02/19/qml-with-akonadi-or-how-to-use-
> >> your-existing-model-view-design-with-qml/
> > 
> > Thanks Steve, but then I'm having the same problem as with
> > QList<QObject*> models. In both cases they are accessed in a different
> > way compared with QML ListModels.
> > 
> > Maybe we could write a generic wrapper like, for example, ListModel<T>
> > that would expose all properties of the containing type T as roles. Not
> > sure if that is possible, though. It's just a couple of days since I'm
> > in Qt land :)
> 
> One of the reasons I haven't done this for QObjectListModel is because it is not very pretty/fast with our current model API -- the model would have to monitor all changes to the object's properties, and emit dataChanged appropriately. 
> 
> With object, the binding below is automatically updated when the object's name property changes (thanks to NOTIFY):
> Text { text: model.object.name }
> 
> In the binding below, the model needs to know when the name property of the object changes, so it can emit dataChanged, causing the binding to update:
> Text { text: model.name }

Thanks for the explanation. It's much clearer now. Just to make sure I
did completely understand the issue: The performance issue is also valid
for custom models based on QAbstractListModel, right? There the
situation is the same that whenever a property of a contained object
changes, the model needs to be informed and the model then informs the
view? 

> I think having the single "object" role is probably still the best solution for QObjectListModel, but I agree it is annoying that this doesn't fit in well with doing dummydata.

I see your point, but also I feel that using dummydata is very important
for me. So for now I'll stick to my QAbstractListModels. When the fix,
you posted earlier, is released, it should be possible to construct
dummydata that is compatible with QObjectListModel. I'll then give it
another try.

For now, thanks a lot for all the support. It's really a great list with
very helpful people here :)

Cheers,
Conny