>
> charley asketh:
> > (1) Logically, should the "state" for MyAttachedProperties simply reside
> within the QObject meta-object system (e.g., through the QObject (base)
> "property()/setProperty()")? Or, can I have my own "state" in data members
> for MyAttachedProperties that I "expose" as properties, or explicitly set as
> properties within the QObject (base) meta-object?
> >
> > (2) In the event I have application-specific types/state in
> MyAttachedProperties, what "synchronization hooks" are assumed to be used to
> expose that state to QML elements? (For example, to translate
> application-specific type state to QVariant values useful to QML elements?)
>
Bea respondeth:
> The docs on attached properties could probably be expanded, if you have any
> suggestions. Can you clarify what you mean here? Are you asking whether it's
> worth exposing data as actual properties for an attached object? And what do
> you mean by 'assumed' synchronization hooks?
>
First, I'm not exactly sure how to use attached properties: If from QML I
wanted to do something like:
//...in QML
myCppClass.myprops.b.c.d: 42
...does this mean I can have MyAttachedProperties "myprops" attached to
MyCppClass, and the "b.c.d" is logically nested *within"
MyAttachedProperties? Is this the reason for MyAttachedProperties, or is
there another way to merely nest "MyCppA" inside "MyCppB" inside "MyCppC"
with an exposed property "d"? For example, if I could expose *any* class as
a nested thing (recursively), would I need to use attached properties at
all?
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?
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.)
In the case that *both* these mechanisms exist, I'm curious how to ensure
they are synchronized (e.g., application-specific state as data members
exposed through explicit properties, or properties defined through the
meta-object system). (I understand the "NOTIFY" solution for Q_PROPERTY --
are there any other mechanisms?)
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?
> (3) Are there examples showing use of "attached properties" other than
> what is mentioned in the "Birthday" example in the Qt 4.7 docs? (I didn't
> find anything else, or anything else on the web ... ?) Specifically, I'd
> like to see examples of "recursive grouped" attached properties state like
> the docs mention is possible, such as binding a value within QML like
> "a.b.c.d.e: 42"
> >
>
> The QGraphicsLayouts examples use attached properties, but they probably
> don't expand on anything beyond what is in the birthday example:
>
>
> http://doc.qt.nokia.com/4.7-snapshot/declarative-cppextensions-qgraphicslayouts-qgraphicsgridlayout.html
>
> http://doc.qt.nokia.com/4.7-snapshot/declarative-cppextensions-qgraphicslayouts-qgraphicslinearlayout.html
>
> In terms of recursively accessing properties, I assume if Birthday.rsvp was
> not a date value, but instead was a custom 'Rsvp' object containing a
> 'date' value, then it could be accessed as "Birthday.rsvp.date".
>
So, to do "Birthday.a.b.c.d", I would need to define a custom attached
properties "a", with a nested attached properties "b", with a nested
attached properties "c", that has a property "d"?
Ok. I just need to figure out the "state synchronization" thing.
(In my specific case, I'm attempting to create an "adapter layer" to expose
a lot of state to QML from a pre-existing application-specific type that has
lots of state.)
Thanks!
--charley
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
