Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Using QML with a framework with its own introspection library
bschindler last edited by
In my company, we are currently investigating using QML for the User interface for our framework. The main issue is this: We have our own serialization/deserialization/introspection framework and the bulk of the classes do not inherit from QObject and making them QObject's is currently not an option. Yet, when I want to use functionality or data from such a class, it needs to be registered and for this, only QObjects with all the appropriate Q_ATTRIBUTE, Q_INVOKABLE etc attributes are acceptable.
I'd like to get some ideas on strategies on how to be able to bridge the two systems. Right now, I don't see any way of using instances of our system directly - I think a wrapper class (adapter) is needed. Correct me if I'm wrong.
I currently see two options:
- Create a (clang-based) compiler which creates a wrapper class for each of the classes
- Create a template class, which has a custom implementation of the QMetaObject
Is this analysis correct and if so, which option do you see as more viable or am I missing something?
Hi and welcome to devnet,
I'f rather go with number 1. Template classes with QObject as base class is currently not supported.
However do you really need all of your framework classes to work with QML or only a subset ?
bschindler last edited by bschindler
I definitely do not need all of them, but a significant amount of them, surely more than a handful. I just imagine the horror of keeping dozens of hand-written wrapper classes in sync with the referenced classes... yet certainly something that could be an option as well..
You say that template classes and QObject are not supported - in which way? I mean, having a custom QMetaObject implementation would make it unnecessary to run moc over the class, sure. Are there other reasons this would not work?
Upon reading http://stackoverflow.com/questions/4397478/qt-templated-q-object-class, I have the impression that this might be possible after all...
Qt Quarterly 15 explains nicely your options