As of Exposing Attributes of C++ Types to QML classes used with QML have to be <code>QObject</code>s. Any chance I can use non <code>QObjects</code> s (aka POCO, not derived from <code>QObject</code>, 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 <code>QObject</code>. Or is there a way to implicitly convert to a QML compliant type so I do not need to wrap at all?

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: <ul> <li>if objects in question can be QObjects, measure the performance (and if it's ok, stick with it)</li> <li>if not, attempt passing opaque PODs by value, if it works, create wrapper scaffolding, and see if it's faster / gives better memory usage than the previous option</li> <li>if no bindings to proerties are needed, and dynamism is required, investigate a) nested QVariants b) dynamic QObject properties</li> <li>if extreme speed / mem requirements should be met, consider writing a tool that auto-generates wrappers and hooking it into the Qt project build pipeline</li> </ul> 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: <ul> <li>POD</li> <li>list</li> <li>QObject</li> <li>variant (not watched for member changes, iirc)</li> </ul>

Any chance to use non QObject classes with QML

As of Exposing Attributes of C++ Types to QML classes used with QML have to be QObjects. 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?

How connect C++ to QML?

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.

What is Q_property in QML?

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.

What is QObject in Qt?

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:

if objects in question can be QObjects, measure the performance (and if it's ok, stick with it)
if not, attempt passing opaque PODs by value, if it works, create wrapper scaffolding, and see if it's faster / gives better memory usage than the previous option
if no bindings to proerties are needed, and dynamism is required, investigate a) nested QVariants b) dynamic QObject properties
if extreme speed / mem requirements should be met, consider writing a tool that auto-generates wrappers and hooking it into the Qt project build pipeline

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:

POD
list
QObject
variant (not watched for member changes, iirc)

Any chance to use non QObject classes with QML

Tags:

c++

qobject

qml

Horst Walter

People also ask

1 Answers

mlvljr

Recent Activity

Donate For Us

Any chance to use non QObject classes with QML

Tags:

c++

qobject

qml

Horst Walter

People also ask

1 Answers

mlvljr

Related questions

Recent Activity

Donate For Us