[Development] QML and QAbstractListModel

[Alan Alpert]

On Thu, Jan 10, 2013 at 11:06 AM, Charley Bay <charleyb123 at 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