Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. Q_INVOKABLE vs signal from QML to C++: Best practice
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Unsolved QML and Qt Quick
6 Posts 4 Posters 4.8k Views 2 Watching
  • 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 Offline
    M Offline
    maxwell31
    wrote on last edited by
    #1

    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?

    KroMignonK 1 Reply Last reply
    0
    • sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #2

      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
      3
      • M maxwell31

        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?

        KroMignonK Offline
        KroMignonK Offline
        KroMignon
        wrote on last edited by KroMignon
        #3

        @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
        4
        • M Offline
          M Offline
          maxwell31
          wrote on last edited by
          #4

          @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

          KroMignonK T 2 Replies Last reply
          0
          • M maxwell31

            @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

            KroMignonK Offline
            KroMignonK Offline
            KroMignon
            wrote on last edited by
            #5

            @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
            0
            • M maxwell31

              @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

              T Offline
              T Offline
              Tom_H
              wrote on last edited by
              #6

              @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
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved