Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Brainstorm
  4. reducing signal/slot indirection

reducing signal/slot indirection

Scheduled Pinned Locked Moved Solved Brainstorm
10 Posts 4 Posters 2.8k Views
  • 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
    mzimmers
    wrote on 6 Nov 2018, 22:45 last edited by
    #1

    Hi all -

    Early in my (still young) Qt education, I was advised that it was acceptable practice to use slots to relay the signal on to another object, perhaps in a different thread, that the signaler couldn't see.

    I fear that I've taken this to an extreme in my current project. I have a worker thread as well as my main (UI) thread. Both my worker object and my main UI object have private objects that raise signals that need to be passed along to the other main object. So, I do a lot of signalling. Here's an example: if my user presses a cancel button on a file transfer dialog, the dialog must signal the main UI (who owns the file transfer dialog), who in turn informs the worker, who in turn signals the file transfer object. That's three pairs of signals/slots. These add up fast.

    I realize that from a performance standpoint, this is fine, but coding clarity suffers. Is this just how it has to be in Qt land, or am I unaware of a more parsimonious alternative?

    K 1 Reply Last reply 8 Nov 2018, 13:53
    0
    • S Offline
      S Offline
      SGaist
      Lifetime Qt Champion
      wrote on 6 Nov 2018, 22:50 last edited by
      #2

      Hi,

      Did you already use signal chaining ?

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      1
      • M Offline
        M Offline
        mzimmers
        wrote on 6 Nov 2018, 22:53 last edited by
        #3

        Hi SGaist - I'm not finding much documentation on that term. Can you give me a short definition?

        1 Reply Last reply
        0
        • S Offline
          S Offline
          SGaist
          Lifetime Qt Champion
          wrote on 6 Nov 2018, 22:56 last edited by
          #4
          class MyCoolClass : public QObject
          {
              Q_OBJECT
          public:
              MyCoolClass(QObject *parent = nullptr) :
              QObject(parent)
              {
                  connect(&timer, &QTimer::timeout, &MyCoolClass::timeout);
              }
          signals:
              void timeout();
          private:
              QTimer timer;
          }
          

          Interested in AI ? www.idiap.ch
          Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

          1 Reply Last reply
          2
          • M Offline
            M Offline
            mzimmers
            wrote on 6 Nov 2018, 23:03 last edited by
            #5

            A connect() call with only 3 arguments?

            1 Reply Last reply
            0
            • S Offline
              S Offline
              SGaist
              Lifetime Qt Champion
              wrote on 6 Nov 2018, 23:11 last edited by
              #6

              It's equivalent to:

              connect(&timer, &QTimer::timeout, this, &MyCoolClass::timeout);

              Interested in AI ? www.idiap.ch
              Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

              1 Reply Last reply
              0
              • M Offline
                M Offline
                mzimmers
                wrote on 6 Nov 2018, 23:13 last edited by
                #7

                OK, so then what you're accomplishing is the elimination of a slot routine, yes? That would be a big help.

                Is this documented anywhere? I searched for the word "chain" in one of the signals and slots pages, and it came up empty.

                J 1 Reply Last reply 7 Nov 2018, 01:21
                0
                • M mzimmers
                  6 Nov 2018, 23:13

                  OK, so then what you're accomplishing is the elimination of a slot routine, yes? That would be a big help.

                  Is this documented anywhere? I searched for the word "chain" in one of the signals and slots pages, and it came up empty.

                  J Offline
                  J Offline
                  JKSH
                  Moderators
                  wrote on 7 Nov 2018, 01:21 last edited by
                  #8

                  @mzimmers said in reducing signal/slot indirection:

                  Is this documented anywhere? I searched for the word "chain" in one of the signals and slots pages, and it came up empty.

                  It's not very clear, but the Signals & Slots page says, "You can connect as many signals as you want to a single slot, and a signal can be connected to as many slots as you need. It is even possible to connect a signal directly to another signal. (This will emit the second signal immediately whenever the first is emitted.)"

                  Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                  1 Reply Last reply
                  6
                  • M mzimmers
                    6 Nov 2018, 22:45

                    Hi all -

                    Early in my (still young) Qt education, I was advised that it was acceptable practice to use slots to relay the signal on to another object, perhaps in a different thread, that the signaler couldn't see.

                    I fear that I've taken this to an extreme in my current project. I have a worker thread as well as my main (UI) thread. Both my worker object and my main UI object have private objects that raise signals that need to be passed along to the other main object. So, I do a lot of signalling. Here's an example: if my user presses a cancel button on a file transfer dialog, the dialog must signal the main UI (who owns the file transfer dialog), who in turn informs the worker, who in turn signals the file transfer object. That's three pairs of signals/slots. These add up fast.

                    I realize that from a performance standpoint, this is fine, but coding clarity suffers. Is this just how it has to be in Qt land, or am I unaware of a more parsimonious alternative?

                    K Offline
                    K Offline
                    Konstantin Tokarev
                    wrote on 8 Nov 2018, 13:53 last edited by
                    #9

                    @mzimmers FYI, if you find yourself doing a lot of signal forwarding, you may want to consider using Observer pattern instead. In this case you forward observer object once to your "deepest" class which emits signals, and call observers virtual methods directly to "emit signal"

                    1 Reply Last reply
                    4
                    • M Offline
                      M Offline
                      mzimmers
                      wrote on 9 Nov 2018, 16:00 last edited by
                      #10

                      Thanks, Konstantin. I'll keep that in mind for future projects.

                      1 Reply Last reply
                      0

                      5/10

                      6 Nov 2018, 23:03

                      • Login

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