[Qt-qml] How to think about Attached Properties?

[Charley Bay]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20101201/b78221b2/attachment.html