As of Exposing Attributes of C++ Types to QML classes used with QML have to be QObject
s. Any chance I can use non QObjects
s (aka POCO, not derived from QObject
, but registered with Qt metasystem)?
If not, is there a simple generic wrapping system to make my objects QML compliant. One I can think of is to add dynamic properties to a simple QObject
.
Or is there a way to implicitly convert to a QML compliant type so I do not need to wrap at all?
Connecting to QML Signals All QML signals are automatically available to C++, and can be connected to using QObject::connect() like any ordinary Qt C++ signal. In return, any C++ signal can be received by a QML object using signal handlers.
Exposing Properties. A property can be specified for any QObject-derived class using the Q_PROPERTY() macro. A property is a class data member with an associated read function and optional write function. All properties of a QObject-derived or Q_GADGET class are accessible from QML.
QObject is the heart of the Qt Object Model. The central feature in this model is a very powerful mechanism for seamless object communication called signals and slots. You can connect a signal to a slot with connect() and destroy the connection with disconnect().
This is one hot topic actually.
I believe you may register your own PODs and pass them around ito and within the QML side (just as black boxes -- w/o any member access, have never tried that). To access the members, some get/set wrapper code could be used, either in form of methods on a QML singleton, or on a QtObject descendant effectively serving as a per-instance wrapper.
Dynamic properties are not currently supported -- you can make them work probably with some quite weird trickery, but it will not probably be worth it (but if you don't want to bind to properties, things will get much-much simpler, and it still will be QObjects).
Implicitly converting would mean having some sort of preprocessor (which is doable probably but would cost lots of time, and a sudecution to submit the result back into Qt (and support it for life)).
I'd go this way:
Thing is, custom PODs don't enjoy the same level of support the built-in do, and the standard language practices are built around manipulating garbage-collected QObject instances (passed everywhere by pointer, of course), which have watched-for-changes properties of types:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With