[Development] On QML, ownership, QObject-trees and QSharedPointer

Kent Hansen kent.hansen at nokia.com
Fri May 25 07:32:44 CEST 2012

Den 25. mai 2012 02:35, skrev ext christopher.adams at nokia.com:
> Hi,
>>> In QtQuick 2.0 (ie, Qt 5.0), we are thinking about using property var
>>> more often in the implementation (eg, of qobject-derived-type
>>> properties) to avoid some of those edge-cases, and providing more
>>> consistent (and useful) referencing semantics.
>> Can you say what 'var' is and why it would help?
> In QtQuick 1.x, you could not define a "JavaScript var-type property" in a QML item.  The closest thing provided was "property variant" which, internally, is a QVariant.  Assigning a JavaScript object to that property would result in it being converted to a QVariantMap.  Accessing that property from JS would result in that QVariantMap being converted back into a JS object.  You could not store a JS function reference, or any other "special" JS value in a "property variant" property (eg, null, undefined).
> In QtQuick 2.0, we deprecated "property variant" and added "property var".  Internally, "property var" properties are JS values.  Thus, you can store anything created in JS, including JS function references.  This allows greater dynamicity and flexibility.  Only when you access that property from C++ (via QObject::property() or QQmlProperty::read()) will it be converted to a QVariant (following the same conversion rules as for any other JS value to QVariant conversion).

Also note that when you implement types on the C++ side, you can use the 
QJSValue class as a property or method parameter to transfer values 
between C++ and QML/JS without type/data loss. This also includes JS 
functions; for example, you can assign a function to a property from QML 
and call it later from C++ using QJSValue::call().

There's also QJson{Value,Object,Array} integration.

Best regards,

More information about the Development mailing list