Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Unsolved Q_INVOKABLE vs signal from QML to C++: Best practice

    QML and Qt Quick
    4
    6
    1849
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      maxwell31 last edited by

      Hi,

      I wonder what is the best way about connecting my qml ui with my c++ backend. Often, I was using Q_INVOKABLE functions directly in qml, e.g. if I would have abutton which says start, I would call the Q_INVOKABLE function start instead of sending a signal and connecting it to a start slot.

      What is considered the best practice with respect to code architecture?

      KroMignon 1 Reply Last reply Reply Quote 0
      • sierdzio
        sierdzio Moderators last edited by

        I don't think either is considered good or bad - both solutions work and make sense. Pick whatever feels better to you in that particular project.

        (Z(:^

        1 Reply Last reply Reply Quote 3
        • KroMignon
          KroMignon @maxwell31 last edited by KroMignon

          @maxwell31 There are no really good or bad about Q_INVOKABLE or Q_PROPERTY (signals/slots). It depends what you want to achieve.
          Using Q_INVOKABLE gives you the possibility to have return value, which is not possible with signals, for example. But in the other hand, with signals you can ensure function is called in the right thread, with Q_INVOKABLE it will be executed in the QML thread.

          So, as I written before, it depends on your use case!

          It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

          1 Reply Last reply Reply Quote 4
          • M
            maxwell31 last edited by

            @KroMignon
            Is the qml-thread different from the thread where the object having the q_invokable as a member is living?

            I am asking this because we had some discussions about using a Q_INVOKABLE breaking encapsulation.

            To me it feels more natural using a Q_INVOKABLE as you immedeatly see what a button will do, and otherwise you need to check the connection first. Another developer was arguing that using Q_INVOKABLE is bad because it forces you to know the C++ structure in QML. My view is that using signals and doing the connection forces you to know the UI structure in C++, which I consider worse

            KroMignon T 2 Replies Last reply Reply Quote 0
            • KroMignon
              KroMignon @maxwell31 last edited by

              @maxwell31 said in Q_INVOKABLE vs signal from QML to C++: Best practice:

              Is the qml-thread different from the thread where the object having the q_invokable as a member is living?

              I would reply to this with "it depends" ;-)
              With some QML backends, the QML Engine is using 2 thread to work: one thread to prepare the display and one thread to do the display.
              And on C++ side, it is up to you to decide in which thread the QObject is living!
              So yes, there is no absolut garantie QML and you C++ object instance are living in same thread.

              Take a look at the webinar about QML / C++ to get some good ideas about how to separate QML and C++: https://resources.qt.io/qt-virtual-tech-con-2020/c-to-qml-animations-12th-may-12-pm-pst

              It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

              1 Reply Last reply Reply Quote 0
              • T
                Tom_H @maxwell31 last edited by

                @maxwell31 If unsure, it's not a bad idea to log the thread with QObject::thread(). That's what I did. It's not a thread ID, just a pointer value.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post