On Wed, 2010-09-15 at 05:53 +0200, [email protected] 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 _______________________________________________ Qt-qml mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-qml
