Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Best Practice: C++, QObjects and Qml ?



  • Hi there,
    I hope to get some advice from an experienced developer, which way to use QObjects is the smartest.
    Currently I’m getting values in a separate C++ Runtime, send them to a QObject, where it does some very simple calculation and then sends a signal to a Qml “sourcevalues” file, where the values and properties of some Objects are getting change, which I display in my GUI.

    fe3ee050-b766-4b77-ac43-03ac680ee2e3-image.png

    Now I want to send more values from my separate Runtime to change more qml Objects.
    All of it should be kind of modular, so it should be very easy to add more Values in my separate Runtime and add more Qml Objects which again are changed by the values.
    So, is it smarter to have one Qml Object, which has many Slots and Signals, do all of the work? Or is it smarter to have several Qml Objects, which all have one signal and one slot, and take care of one Qml Object?
    Option 1: One QObject, One Connection.
    3f864ce2-00bb-49a9-ade4-937ef08c0749-image.png
    Option 2: Several QObjects, each handling its own Qml Object
    16e2370f-d4fd-4b86-8888-90045e9a184e-image.png

    I tend to implement the second approach, because i think it might be more transparent and flexible, to add a QObject each time i want extract another values in the runtime and create another object that displays it instead of putting my different slots and signals in one QObject.
    But I don't know whether it slows the GUI down, by adding a connection for each new QObject.

    Any advice?

    Kind regards & happy new year



  • @Philomath-Qt said in Best Practice: C++, QObjects and Qml ?:

    so it should be very easy to add more Values in my separa

    Are there logical groupings for these values or are they completely independent?

    The way I ordinarily handle data like this is to provide it via a C++ data model that is injected into the engine context. I would provide properties in that model so the QML can bind to them and the updates are handled automatically. If ValueSource.qml is just an item with a collection of functions that can be used to connect to a UI element, it seems like you can eliminate that and implement the model approach I mentioned above.

    Look at QAbstractItemModel or one of the other model classes.

    Another approach is to create a QObject derived class and create a QVariantList Q_Property and use that as a data model. That would be closer to your option one.

    The thing that sticks out to me about your design is the ValueSource.qml. In my opinion, data models belong in C++, and for that matter the QML should be reasonably free of javascript.



  • @Philomath-Qt said in Best Practice: C++, QObjects and Qml ?:

    so it should be very easy to add more Values in my separa

    Are there logical groupings for these values or are they completely independent?

    The way I ordinarily handle data like this is to provide it via a C++ data model that is injected into the engine context. I would provide properties in that model so the QML can bind to them and the updates are handled automatically. If ValueSource.qml is just an item with a collection of functions that can be used to connect to a UI element, it seems like you can eliminate that and implement the model approach I mentioned above.

    Look at QAbstractItemModel or one of the other model classes.

    Another approach is to create a QObject derived class and create a QVariantList Q_Property and use that as a data model. That would be closer to your option one.

    The thing that sticks out to me about your design is the ValueSource.qml. In my opinion, data models belong in C++, and for that matter the QML should be reasonably free of javascript.



  • Hello @Jhorns2 thank you for your suggestions!

    @Jhorns2 said in Best Practice: C++, QObjects and Qml ?:

    Are there logical groupings for these values or are they completely independent?

    The values are generally independent and got one own Qml Object, that display it in someway. In some cases i have to add two values for one Object, but nothing very complex.

    Sorry for my amateur questions, i'm very new to this:

    @Jhorns2 said in Best Practice: C++, QObjects and Qml ?:

    C++ data model that is injected into the engine context.

    Which kind of c++ data model are you talking about? Are you still talking about something that inherits from a QObject? Because i thought this is the only way to inject an Object into the engine context.

    Do i get you right; generally you recommend me, that i use Q_Properties, which i overwrite in my C++ Runtime and bind them to my GUI Objects, instead of using my signal-slot approach?

    Currently my calculations or done in the QObject, the ValueSource.qml doesn't involve calculations. I Just thought it might be easier to update the values of all GUI Object in one qml file, instead of writing a own connection into every window or GUI object.
    My general goal is to create a concept, that makes it very easy for the next person to modularly add new GUI object, which display new values from my separate runtime. I thought i might just write a basic template for a QObject and instructions how to use it. But maybe it's smarter to use Q_Properties as you are saying.



  • @Philomath-Qt said in Best Practice: C++, QObjects and Qml ?:

    Which kind of c++ data model are you talking about? Are you still talking about something that inherits from a QObject? Because i thought this is the only way to inject an Object into the engine context.

    Do i get you right; generally you recommend me, that i use Q_Properties, which i overwrite in my C++ Runtime and bind them to my GUI Objects, instead of using my signal-slot approach?

    Yes, you can either create a QObject derived class with Q_PROPERTY properties and bind to those, or you can create a QAbstractItemModel or some other Qt Model derived class and use that as a model.

    Currently my calculations or done in the QObject, the ValueSource.qml doesn't involve calculations. I Just thought it might be easier to update the values of all GUI Object in one qml file, instead of writing a own connection into every window or GUI object.

    If you create a model and inject that model (QObject derived class, as you say) into the context, you can bind your QML code to the properties of your model. The binding approach means you don't need an explicit Connection item in QML. You simply assign MyModel.propertyName to your QML property and it will automatically update when your data changes, assuming you set up the model with the appropriate signals to notify when the data in the model is updated on the C++ side.

    My general goal is to create a concept, that makes it very easy for the next person to modularly add new GUI object, which display new values from my separate runtime. I thought i might just write a basic template for a QObject and instructions how to use it. But maybe it's smarter to use Q_Properties as you are saying.

    The Q_PROPERTY is required to be in a QObject derived class. Take a look at the Q_PROPERTY documentation, it will be helpful.



  • Hey @Jhorns2 , thank you very much, your approach sounds much smarter than mine, I really appreciate your advice.
    If i get you right, i can skip the ValueSource.qml, where i create some properties and change them with an explicit connection to my QObject, and instead i can link the Q_Properties to the properties of my Qml Object directly.
    I thought the ValueSource.qml would be smart to bundle the properties at one place, but doing everything already in the QObject with Q_Properties seems to be even more transparent.
    I will also take a look at QAbstractItemModel and other model classes, whether they are an even better alternative.

    Thanks again


Log in to reply