[Qt-interest] Signal chaining

[Andreas Pakulat]

On 29.03.10 16:44:29, Mandeep Sandhu wrote:
> On Mon, Mar 29, 2010 at 4:32 PM, Andre Somers <andre at familiesomers.nl> wrote:
> > On 29-3-2010 12:47, Mandeep Sandhu wrote:
> >> Hi All,
> >>
> >> I have a requirement where I need to send out a notification (as a
> >> signal) to the user of my lib. The lib internally uses other helper
> >> classes for getting the notification. These classes are not exposed
> >> outside. All classes are QObjects.
> >>
> >> Eg: Class A (ext visible) --uses-->  Class B (internal) --uses-->Class
> >> C (internal)
> >>
> >> One way is to emit signal from C, connect it to B, which in turn would
> >> "re-emit"  it out to A, and so on (All signal-slot connections will be
> >> direct (not queued) since it operates in a single thread's context).
> >>
> >> Would it be lighter to use simple callbacks? (but then I would need
> >> the inner most class "C" to know about "A", since  finally A emits it
> >> out to a "user")
> >>
> >> I'm running this in an embedded box and was worried about the overhead
> >> of chaining these signals. If it's not much, I would prefer to use
> >> signals.
> >>
> > How about just connecting the internal signals to the signals in the
> > external API directly? You can connect signals to signals. There is no
> 
> Hmmm....it's nice to connect signal to signal. Those re-emitting slots
> looked bad! :)
> 
> But for connecting signal of C to signal of A, I'll need to have C
> visible in A (which I was trying to avoid, since C's something thats
> for B's internal use! :)).

No you don't. You only need A and C visible in B, which can then make the
connection. Thats another nice thing about Qt's signal/slots you can
connect "arbitrary" objects with one another. The objects don't have to
have any clue about each other.

Andreas

-- 
You can do very well in speculation where land or anything to do with dirt
is concerned.