Does a derived class inherit its base class's meta properties, even without QObject?
according to this thread QObject derived classes always inherit the
Q_PROPERTY()declarations of the base classes.
However, what about
Q_GADGETwhich is lighter than
I can't make my class derive from QObject (I need copy semantics e.g.) and therefore I use the
Q_GADGETmacro instead of
From my experiment, it seems like now the QML properties aren't inherited. Is there any way on how to inherit the properties or is this an intentional limitation?
In the end I could also switch to composition instead of inheritance in my case, i.e. use the base class as a member, which then should make the properties available, if I add a single
Q_PROPERTYfor the member. However, inheriting those properties would be easier for me, so can you guys give me any info on whether this can work?
What are you copying from your custom class ?
Magnus21 last edited by Magnus21
@SGaist Pretty much the entire class. Its members are mostly primitive types, all available with copy semantics themself.
If you really need your class to be a
QObject, then what about implementing a clone function ? You create a new object where you copy all members and you're good to go.
@SGaist Not really. I don't think this workaround is suitable to every use case.
Consider for instance the possibility that I want to insert my class into a
std::vector. The vector insert operation always uses copy semantics, so there is no way how I could insert the class into a vector. And afaik move semantics don't work with
Use pointers to
QObjectwhen using them with
@SGaist What about smart pointers? Is there a way to get a
I am not using the Qt way of parent ownership, because I prefer the smart pointer approach. I think there is no way to
QObject, is there? This would probably require copy semantics somewhere to work.
You would likely have to use std::make_shared.
But bewarel, you have to take good care of knowing when your objects might get parented (for example putting a widget in a layout) or when ownership is taken by the called class (for example QTableWidget::setCellWidget).
You are likely going to make your life difficult by wanting to avoid Qt's ownership paradigm while writing a Qt application.
Alright, now what about propagating those members to QML.
If I decide to store pointers to custom classes, would I register the pointer to the class for QML to somehow make QML understand the pointer, or would I rather always dereference the pointer at the last step before propagating it to QML?