Ok, follow-up, I'm still trying to understand setting properties in the QObject::setProperty() meta-object system versus exposing a data member as a property (and how these options relate to attached properties).
Reading the QML docs: <http://doc.qt.nokia.com/4.7-snapshot/qtbinding.html> QUOTING DOCS: >>>>>>>>>>>> You should always use QObject::setProperty<http://doc.qt.nokia.com/4.7-snapshot/qobject.html#setProperty>(), QDeclarativeProperty<http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeproperty.html>or QMetaProperty::write<http://doc.qt.nokia.com/4.7-snapshot/qmetaproperty.html#write>() to change a QML property value, to ensure the QML engine is made aware of the property change. For example, say you have a custom element PushButtonwith a buttonText property that internally reflects the value of a m_buttonTextmember variable. Modifying the member variable directly like this is not a good idea: // BAD! QDeclarativeComponent component(engine, "MyButton.qml"); PushButton *button = qobject_cast<PushButton*>(component.create()) button->m_buttonText = "Click me"; Since the value is changed directly, this bypasses Qt's meta-object system<http://doc.qt.nokia.com/4.7-snapshot/metaobjects.html>and the QML engine is not made aware of the property change. This means property bindings to buttonText would not be updated, and any onButtonTextChanged handlers would not be called. <<<<<<<<<<<<< QUOTING DOCS Ahhh..... there it is ... it's better to rely upon your state *within* the QObject::setProperty() system (to ensure modification notifications). Seems reasonable. However, since I'm maintaining application-specific state in application-specific types, and exposing that state to QML (from C++), I'll have to manage a "synchronization" between the "real" application-specific-state-in-application-specific-types with those values that I explicitly set/update in the QObject::setProperty() (meta-object) world. Interesting problem. Back to the original thread on attached properties, I'd *like* to implement a single QObject "wrapper" of an application-specific type with (deep) state, and make that available to QML (as attached properties on some other C++ QML-exposed class). Since the state is "deep", the "a.b.c.d" syntax would be great for access. Is this one kind of intended use for "attached properties" (centralized wrapper-exposure of application-specific state, uncoupled from a given application-specific type)? Another option would be to merely expose a QObject-derived class explicitly at each level for "a.b.c.d", and not use attached properties at all. Hmmm.... --charley
_______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
