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

[bea.lam]

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

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

[Charley Bay]

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:



QUOTING DOCS:  

You should always use
QObject::setProperty(),
QDeclarativePropertyor
QMetaProperty::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(component.create())
 button->m_buttonText = "Click me";

Since the value is changed directly, this bypasses Qt's meta-object
systemand 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

Re: [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
___
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml

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

[bea.lam]

Hi Charley,

On 27/11/2010, at 11:45 AM, ext Charley Bay wrote:

> I'm implementing "attached properties" on my custom C++ type (exposed to 
> QML), and am unsure about the "proper" use model:
> 
> 
> 
> For example, I did:
> 
> (a) Implement C++ class MyAttachedProperties, derived from QObject
> 
> (b) Implement static function and QML_DECLARE_TYPEINFO on C++ 
> MyClassWithAttachedProperties so QML triggers instantiation of the attached 
> properties object.
> 
> The above seems to work fine.  My questions:
> 
> (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?)

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?


> (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".


regards,

Bea


___
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml