Basic language types implementation
-
Do the "primitive" QML types like bool, int, real, etc. inherit QObject in order to implement an onChanged signal or is there some other mechanism that avoids the overheads of QObject?
I need to implement a few such custom "primitive" types so I wonder what approach should I take. Both signals and slots as well as putting anything into QML require to inherit at least QObject but it does seem a lot of overhead for a primitive type. So is there any special "magic" behind QML basic types or is it the straightforward approach - inheriting QObject and declaring the onChanged signal?
-
The documentation of "QML Basic Types":http://qt-project.org/doc/qt-5.0/qtqml/qtqml-typesystem-basictypes.html states:
bq. Some basic types have properties: for example, the font type has pixelSize, family and b properties. Unlike properties of object types, properties of basic types do not provide their own property change signals.
-
That makes sense. Never really tried to use a basic property changed signal, don't even know why I assumed there is such a thing, against all logic. I am not in the habit of reading the documentation start to finish, usually just looking up what I specifically need.
-
The change signal for the basic property itself will be emitted by the "owning" object instance. But changes to subproperty values (such as the a/r/g/b components of a color property, or the x/y/z components of a vector3d property) do not cause subproperty change signals to be emitted (eg, there's no vector3d.onXChanged() signal); instead the coarse-granularity change signal for the entire property will be emitted.
To implement a custom "primitive" type, you can either register it as a value-type (see how the QVector3D type is registered as vector3d by the QtQuick module in QtQuick2) or simply derive from QObject directly and provide property accessor/mutator/notify functions/signals as required.
Cheers,
Chris. -
In qquickvaluetypes.cpp from src/quick/util directory.
Note that the QtQuick valuetypes are "special" in that (in order to save time) we hardcoded the property type names into the QML engine (actually, into the parser, but I digress). We intended (for 5.1) to modify the registration API so that typenames could be supplied also, but it never happened for obvious reasons.
The QtLocation module does register some valuetypes of its own, which can be assigned to variant properties. Take a look at that if you want a good example. Although to be honest, given the immaturity of the (undocumented / private) registration API, it's probably best to use a QObject-derived type instead.
Cheers,
Chris. -
I doubt it will happen for 5.2 now, unless someone puts in the work.
The limitation is that the custom basic types will work, but they will be "backed" by a variant - which means that type safety won't be enforced at the parser level for them (I think - my memory is fuzzy, but that's my recollection). QtLocation does expose eg GeoCoordinate as a valuetype, so it can be done (and it "works"), but it's certainly not supported to the extent that would be "good".We ran out of time :-(
Cheers,
Chris.