How to integrate qml with c++ when using stackview?

[Bob64]

@Kamichanw I would consider using a context property to communicate from your QML page to the C++ backend, rather than trying to set up signal connections in the C++ code.

[GrecKo]

@Bob64 context property should be avoided. Prefer Singletons or Creatable types

@Kamichanw can't your QML code call a C++ function instead? It knows what it is interacting with so might as well directly call it. The reverse way (accessing QML objects from c++) should be avoided.

[Bob64]

@GrecKo I think I had heard that QT is encouraging us to go in that direction but I had been stuck on 5.9.6 until recently and old habits die hard.

Do you have a link to the rationale for preferring singletons? It seems odd in this day and age that singletons should be encouraged!

[GrecKo]

@Bob64 context properties are essentially singleton with worth semantics and performance anyway.

QML singletons might not be singleton on the C++ side, it just defines how they are accessed by the QML engine. They provide type safety and tooling support that context properties don't.

[Bob64]

@GrecKo said in How to integrate qml with c++ when using stackview?:

QML singletons might not be singleton on the C++ side

OK, that's a key point for me. I need to look into this in more detail now. Thanks.

[Kamichanw]

@GrecKo Can you explain why we should prefer Singletons or Creatable and when we use context property?

@Bob64 Can you explain why I should call c++ function rather than emit signals and we I should us signals instead of c++ function directly?

[jeremy_k]

Without getting into the discussion about preferred designs, using a relay signal in the top component is easy.

Item {
    id: root
    signal textChanged(string text)
    ChildToBeCreatedLater {
        TextField {
            onTextChanged: root.textChanged(text)
        }
    }
}

[Bob64]

@Kamichanw said in How to integrate qml with c++ when using stackview?:

@GrecKo Can you explain why we should prefer Singletons or Creatable and when we use context property?

I think what GrecKo was saying was that context properties should not be used at all now as that is considered to be a deprecated approach. The advice seems to be: in any case where a context property would have seemed most appropriate (i.e., accessing a C++ API from QML via some named access point), use a singleton instead.

Creatable types are for where it makes sense to implement an object in C++ that looks like a component in QML and can be instantiated in your QML code in the same way you can instantiate a Rectangle or Timer or whatever.

@Bob64 Can you explain why I should call c++ function rather than emit signals and we I should us signals instead of c++ function directly?

Technically it is possible to connect a QML signal to a C++ slot, but I do not think this method is emphasised in the Qt docs and I have never needed to do it myself. I think the main issue with it is that in order to make the connection, you have to go looking on the C++ side for the QML object. The general advice is that you should try to avoid accessing QML objects from C++. For example, see the warning in the Qt docs about half way down this page: https://doc.qt.io/qt-6/qtqml-cppintegration-interactqmlfromcpp.html

The more recommended approaches are described in this doc:

https://doc.qt.io/qt-6/qtqml-cppintegration-overview.html

[jeremy_k]

@Bob64 said in How to integrate qml with c++ when using stackview?:

Technically it is possible to connect a QML signal to a C++ slot, but I do not think this method is emphasised in the Qt docs

https://doc.qt.io/qt-6/qtqml-cppintegration-interactqmlfromcpp.html#connecting-to-qml-signals

The example in the documentation demonstrates connecting to a signal from the root QML item. My example above demonstrates relaying a signal from a non-root, dynamically created item via the root.

[Bob64]

@jeremy_k I completely agree that it's possible and I had even linked to the same page as you. I was simply saying that integrating in the C++ to QML direction seems to go against the grain of what Qt themselves recommend, the warning on that page being being a case in point.