Results 1 to 9 of 9

Thread: Broadcasting a signal ?

  1. #1
    Join Date
    Sep 2009
    Location
    UK
    Posts
    2,447
    Thanks
    6
    Thanked 348 Times in 333 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Broadcasting a signal ?

    I have two widgets, one of which is in a few levels of classes and one which is only 2 levels deep. I'd like the second widget to do some action depending on something happening on the first widget, but neither knows of the others existence, nor could they get a pointer to it very easily (I'd have to make a public variable in each layer of classes to get the pointer. Yeuck)

    Is it possible for one widget to 'broadcast' a signal which the secondary widget can pickup ?

    I really don't want to pass a pointer to the secondary widget through the various constructors to get to the first widget so it can perform a connect() call as I want them to remain completely self contained.

    I've thought about Qt Event system, but that requires a pointer to the object to send the message to, and neither widget knows the pointer to the other.

    I keep thinking of a global class accessible by both where one can register as a listener with a unique id, and the other sends a signal using that same id, but this seem nasty, and too much like signals and slots already implemented.

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,360
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Broadcasting a signal ?

    I would probably reemit the signal from each parent class until it reaches a place where you can connect it to a slot. On the other hand I have strong doubts whether such coupling is a good design at all. If you explained the situation maybe we could find a better solution.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  3. #3
    Join Date
    Oct 2006
    Location
    New Delhi, India
    Posts
    2,467
    Thanks
    8
    Thanked 334 Times in 317 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Broadcasting a signal ?

    I guess socket communication or any other IPC would be better for your case

  4. #4
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,360
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Broadcasting a signal ?

    From what I understood this is not interprocess but rather intraprocess. Sockets would be an overkill here. I have a better solution waiting but I want to know the usecase first.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  5. #5
    Join Date
    Sep 2009
    Location
    UK
    Posts
    2,447
    Thanks
    6
    Thanked 348 Times in 333 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Broadcasting a signal ?

    There were several use cases, but I've since redesigned most of them around other ideas which make more sense.

    The other is that there can be a few widgets that are all self contained, all of which that currently have Activated() and Deactivated() signals. Both signals are connected from every widget in that group to each other. So with 2 widgets there are 4 signals, and for 3 widgets there are 12 signals, and so on. Here I think a broadcast signal from each to all would be better than all thrse signals flying around.

  6. #6
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,360
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Broadcasting a signal ?

    Have a singleton object that emits activated and deactivated signals and connect your objects to that object. As it is a singleton, you can access it from any place in your application thus making it emit proper signals becomes easy.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  7. #7
    Join Date
    Sep 2009
    Location
    UK
    Posts
    2,447
    Thanks
    6
    Thanked 348 Times in 333 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Broadcasting a signal ?

    So instead of each widget talking to each other, they talk to the singleton which will in turn talk to the others? I suppose the singleton would require the use of the sender() method else otherwise it would include the sender in its redistribution of the signals, which would be bad.

    It would also require pre-registration with the singleton to know who to send the signals to, although that wouldn't be too bad, as it could do it when the objects connect() to its signals if Qt has a way of detecting such?

    Or are you thinking something different?

  8. #8
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,360
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Broadcasting a signal ?

    Quote Originally Posted by fatjuicymole View Post
    So instead of each widget talking to each other, they talk to the singleton which will in turn talk to the others?
    Yes.
    I suppose the singleton would require the use of the sender() method else otherwise it would include the sender in its redistribution of the signals, which would be bad.
    Why? If the sender is already disabled, trying to disable it again shouldn't have any effect.
    Besides, instead of disabling the sender in the first place, make it (or the thing that is to disable the object) call the singleton directly and it will emit the signal and effectively disable the object.

    It would also require pre-registration with the singleton to know who to send the signals to
    connect() statement is such a registration. Try this:

    Qt Code:
    1. class Controller : public QObject {
    2. Q_OBJECT;
    3. public:
    4. Controller(){
    5. m_instance = this;
    6. m_active = true;
    7. }
    8. static Controller *instance() { return m_instance; }
    9. bool isActive() const { return m_active; }
    10. public slots:
    11. void setActive(bool v){
    12. if(v==m_active) return;
    13. m_active = v;
    14. emit activeChanged(v);
    15. }
    16. signals:
    17. void activeChanged(bool)
    18. private:
    19. bool m_active;
    20. static Controller *m_instance;
    21. };
    22.  
    23. Controller* Controller::m_instance = 0;
    24.  
    25. // ...
    26.  
    27. class MyObject : public QObject {
    28. Q_OBJECT
    29. public:
    30. MyObject() : QObject(){
    31. m_active = Controller::instance()->isActive();
    32. connect(Controller::instance(), SIGNAL(activeChanged(bool)), this, SLOT(setActive(bool)));
    33. connect(this, SIGNAL(activeChanged(bool)), Controller::instance(), SLOT(setActive(bool)));
    34. }
    35. public slots:
    36. void setActive(bool v) {
    37. if(m_active==v) return;
    38. m_active = v;
    39. emit activeChanged(v);
    40. }
    41. signals:
    42. void activeChanged(bool);
    43. private:
    44. bool m_active;
    45. }
    46.  
    47. #include "main.moc"
    48.  
    49. int main(int argc, char **argv){
    50. QApplication app(argc, argv);
    51. Controller c;
    52. MyObject obj1, obj2;
    53. // effectively these are equivalent:
    54. obj1.setActive(false);
    55. // or
    56. obj2.setActive(false);
    57. // or
    58. c.setActive(false);
    59. // or
    60. QObject::connect(&cb, SIGNAL(toggled(bool)), Controller::instance(), SLOT(setActive(bool)));
    61. cb.show();
    62. return app.exec();
    63. }
    To copy to clipboard, switch view to plain text mode 
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  9. The following user says thank you to wysota for this useful post:

    squidge (16th November 2009)

  10. #9
    Join Date
    Sep 2009
    Location
    UK
    Posts
    2,447
    Thanks
    6
    Thanked 348 Times in 333 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Broadcasting a signal ?

    Quote Originally Posted by wysota View Post
    Why? If the sender is already disabled, trying to disable it again shouldn't have any effect.
    Thanks, having activeChanged is much better than seperate Activated and Deactivated signals. I'll have a play with it tomorrow.

Similar Threads

  1. pthread instead QThread
    By brevleq in forum Qt Programming
    Replies: 8
    Last Post: 23rd December 2008, 07:16
  2. Connection of custon signals/slots
    By brevleq in forum Qt Programming
    Replies: 2
    Last Post: 23rd December 2008, 07:04
  3. Possible signal mapper problem
    By MarkoSan in forum Qt Programming
    Replies: 13
    Last Post: 25th January 2008, 13:11
  4. Replies: 2
    Last Post: 17th May 2006, 21:01

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.