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

[michael.brasser at nokia.com]

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 }

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.

Regards,
Michael