Hi Charley,
>
> In the case where I have MyAttachedProperties, must the nested "b.c.d"
> actually be nested within each other (with each of "b" and "c" derived from
> QObject and exposed to QML), or is there a way I could "map" the "b.c.d" to
> some application-specific attribute within MyAttachedProperties? (For
> example, if "MyAttachedProperties" is merely a wrapper to expose an existing
> application-specific type with rich nested state, it would be nice to merely
> expose its state through a single top-level MyAttachedProperties wrapper.)
>
> Specifically, does attached properties *demand* that each of "b" and "c" are
> derived from QObject?
Yes, the b.c.d notation is for Qt Property access, so "b" and "c" must be
QObject-derived.
>
> A "high-level" question is that since MyAttachedProperties is *already*
> derived from QObject (required to be attached properties), I could in my
> constructor set state through the meta-object system:
>
> MyAttachedProperties::MyAttachedProperties()
> {
> setProperty("myvalue", 42);
> }
>
> Or, I could have a *data member* that tracks this state, and expose it as a
> property:
>
> class MyAttachedProperties
> {
> Q_PROPERTY(int myvalue READ myvalue WRITE setMyvalue)
> int myvalue;
> };
>
> ...would either be accessed from QML, or is there a preference (would only
> one work, or hold preference over the other)? (Yes, I see Q_PROPERTY adds
> type safety.)
Only the second one. Properties that have not been defined with Q_PROPERTY
aren't supported in QML, since it relies on property type information.
> Finally, what about "name collisions"? If I define an application-specific
> property like "width" that happens to "overlap" things that might be in the
> meta-object system, does one replace the other?
I'm not sure on the rules, but from experimentation it seems that if a subclass
has a property with the same name as one in the base class, the inherited
property becomes hidden.
> 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.
Yes, I guess that is one way of using attached properties. It sounds like it
may make sense for your situation as the object does not normally have that
type of property but the application state data can be annotated to the object.
I'd also consider using context properties to access application state data,
as that can also be used to access some sort of b.c.d nested property value.
regards,
Bea
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
