-1

I'm working now with Qt; I'm a bit mystified by their implementation of slots and signals (using 5.4 but could use old syntax too). I've looked all over for a good explanation of this part, but it's eluding me.

I used to create a slot and signal mechanism in other (non-Qt) projects. I'd have a message manager, and a routine with register with it that it wanted to send out a signal. It would send it to the message manager. Likewise a receiver would register with it that it wants to be notified of a signal. It would ask the message manager for that. Then, when a signal occurred, it would route it over to the listener. A sender didn't know how many (if any) listeners it had and a listener didn't know who might send that signal (if any).

I figured Qt worked like this, and I could still fake it by writing my own message manager, but it seems like slots and signals should take care of it. However, in all reading of slot and signal examples, it seems like that when the connection is made you need to know who the sender of the signal would be, and you connect it to your slot. However, what if the signal comes from multiple places? Do you have to wire it up to each and every module? That would seem to defeat the purpose, but every example I find shows it knowing where the signal is coming from.

Any clarification is appreciated.

LPTab
  • 11
  • 3
  • What do you mean by saying _the signal comes from multiple places_? Could you add some (pseudo)code to illustrate what you are trying to achieve? – hank May 07 '15 at 14:42
  • I meant multiple sources could send the same signal. For instance, there might be a signal that said "revertAll" (example). Multiple functions might run into a situation where they have to issue a revertAll. They make a change, but others might want to to, so it sends out a "revertAll" message, not caring who gets it. Likewise a module might need to know when we were reverting, so it can adjust itself. A revertAll could occur in a variety of circumstances, so it's not clear who might send it (and a given module shouldn't have to know in advance about other modules). Like Windows messaging. – LPTab May 07 '15 at 15:10
  • Actually another example is how in Android/Java you can set up listeners. Anyone can listen for an event. Anybody else in that interface can issue an event. You don't have to know where it's going or where it's coming from to make use of it. – LPTab May 07 '15 at 15:17
  • Actually, if you have some global "revertAll" signal you should also have some global object responsible for sending this signal. For example, you can create a singleton class `Manager`, use its unique instance to send `Manager::revertAll` signal and use the same instance in every connect. This would be effectively the same as you describe. However, signals and events are usually not global but bound to some objects instead. There is always something responsible for each particular signal, or it can be put in the main window class as last resort. – Pavel Strakhov May 07 '15 at 16:00
  • That's what it looks like I'll be doing - writing a dispatcher. I don't mind, I've done it before, but I was hoping (from the way it was described) that slots and signals would do it for me. I think I'll just make a dispatch object and various modules can just listen to that object only and not need to know about the other ones. Thanks. – LPTab May 07 '15 at 16:16

1 Answers1

-1

This might shed some light. Taken from http://doc.qt.io/qt-5/signalsandslots.html

Slots are normal C++ functions ...

Marius
  • 1
  • 4