On Thu, Jan 10, 2013 at 11:06 AM, Charley Bay <charleyb...@gmail.com> wrote: > QUESTION: Alan seems to suggest the (C++) QAIM/QML might be changed/updated > in the "near-future" (and that was the purpose for the question in this > thread). Is that to handle the "model" or the "item", or "both"?
Whoa, when I said "maybe it would be better to wait until there's time for a more holistic 'models in QML' update" I was not talking "near-future". I was talking far-future. So if that's what you're referring to then keep in mind I was walking about an open-ended long-term research project. Not something that I think anyone has time to work on this year. In the near-future, all I can say is that QAIM is not off-limits for contributions ;) . > QUESTION #2: I *assumed* (perhaps wrongly) that QAbstractItemModel DID NOT > have "Q_PROPERTY()" things because the "Q_PROPERTY()" is purported to expose > attributes to QML. I see "Q_PROPERTY()" as an "adapter-to-QML". So, it > seemed obvious (to me) that all "Q_PROPERTY()" things would go into > "MyItemModel", and not the "QAbstractItemModel" itself. Any > "common-properties" (like "count()" and "get(int)") could similarly be in a > derived "QAbstractItemModelWrappedForQml". Is the intent to make it > "open-season" on adding "Q_PROPERTY" things to other C++ classes, for those > attributes to be exposed to QML? I'm not sure that's a good idea, because > it seems like the "act-of-wrapping/exporting" to QML is a very different > level API than the act of C++ interfacing with the primitive C++ class. > (This isn't a strongly held view, it's just my current impression.) Q_PROPERTY is not QML specific. A good example (at least, one I ran into recently), was QCoreApplication. It has properties, and they are not because we want to expose QCoreApplication to QML directly. In fact my current implementation of QQmlApplicationEngine writes a QML wrapper object still instead of exposing QCoreApplication (for various reasons). Q_PROPERTY can be added to any QObject subclass same as it could in Qt 4.6. The only difference is to consider the possibility of QML exposure to the extent it makes sense for that class. Which is why some properties that improve QML exposure potential makes sense for QALM, because its subclasses get exposed a lot by user code. We certainly want to be careful about where we actually expose C++ classes to QML. Don't do that unless they have a good QML level API. But that is a separate step to adding properties. I hope no Qt users assume that every QObject derived class in Qt is prepared to work perfectly should they register it into QML themselves. -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development