> Perhaps an alternative approach would be to create a proxy model for > exporting to QML. It could include all the methods you need, but it > would not complicate QAIM itself. It seems to me that all the methods > you need can be implemented in terms of the already existing > functionality in QAIM, so it would work on all of them. Instead of > exposing the C++ QAIM directly, you could create an instance of the > proxy on it and expose that proxy model to QML instead, providing all > the QML specific methods you need without complicating the base QAIM. > > Some of this functionality already exists in VisualDataModel through its items ( http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-visualdatamodel.html#items-prop) property, which among other things provides generic accessors for model data.
There's a tutorial explaining it's use at http://qt-project.org/doc/qt-5.0/qtquick/qtquick2-qml-dynamicview-tutorial.html although all the code snippets seem to have gone missing so its usefulness is somewhat reduced and you might be better off looking at the example source in the qtdeclarative repo (examples/quick/tutorials/dynamicview/) instead. > It would IMHO be even better to get access to the QML model API from > C++, making it possible to build 'native' QML models directly in C++. > Eventually, that will probably happen, but I guess more water will need > to flow through <insert your local major river> before that can be done. > > What's a native QML model? The model types provided by QtQuick are QAbstractItemModel implementations and while the views can accept a few other basic types as model sources the internal abstraction for those types isn't at the model API level but something highly specific to VisualDataModel and wouldn't be of much use to anyone else. Andrew
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
