programming practices with connect

(this is a very general question)

in terms of programming practices, should i avoid bypassing parent widgets when connecting and prefer forwarding signals?

example:
main window
widget1
child1 (has a signal)
widget2
child2 (has a slot)

one option would be to connect in this manner (from main window):
connect( widget1->child1, somesignal,
widget2->child2, someslot );

should i avoid this kind of shortcut and prefer forwarding using signals in widget1 and widget2?

Well that's a matter of personal taste. Both variants are fine, but if you ask: I prefer signal forwarding. This ensures that I can change childX anytime without maintaining code in my main window.

Think about a future. If you'll connect child's signal via manwindow's slot, in future you can use this information. For example for logging or to forwarding data via network, etc

Quote:

---

Think about a future (...)

---

Exactly. If you create connection using main window slots, you can also easy perform filtering and logging on the signal's informations. Personally, I prefer to do that this way than direct connection.

i don't think i completely understood you (borisbn and stampede);
how do you forward?
do you mean you connect a child's signal to a main window slot, and from there emitting the forward signal?
or perhaps a chain of signals leading to destination slots?

Just in case you did not know this:
You can connect signals to signals. That's called signal forwarding.

So all you need to do is declare additional signals for each signal you want to forward in your widget1 and widget2 classes.

in the constructor of widget1 you could then put code like:

Code:

---

connect( child1, SIGNAL( somesignal() ), this, SIGNAL( forwarded_somesignal() ) );

---

I like centralized control of signals, with a bunch of widget signals connected to a central "hub" via signal "spokes". I have had bad experiences connecting signals to one another (forming more of a web, if you will) because maintenance becomes a nightmare, and it's easy to lose track of what's responding to what.

In my latest designs, pretty much everything goes through a central widget, and there is no crosstalk between objects. The only exception is signals that are contained entirely within an object; I don't need to know about those, and the object is free to do whatever it takes to maintain itself.