Signals: Is this the expected behaviour of connect() ?
faure at kde.org
Mon Feb 25 11:08:00 GMT 2008
On Monday 25 February 2008, Thiago Macieira wrote:
> Eduardo Robles Elvira wrote:
> >And indeed, it seems that signals were designed somehow to be only
> > triggered by it's owner (and friends & parents). You cannot do emit
> > new
> >A()->signalA(); inside B. It doesn't even compile because the signal
> >is "protected". But then, as the given code shows, connecting signalB()
> > to signalA() and triggering signalA(), works fine - so maybe this is a
> > bug?
> Signal to signal connection is allowed and part of the design.
Well, yes, but usually that's for relaying signals, not for forcing another unrelated class to emit a signal.
If this kind of use case was part of the design, then "signals:" might as well be defined "public:" instead of "protected:".
I think this is just a side effect of the fact that signal/slots connections bypass private/protected/public protection, but
I certainly wouldn't call this kind of hack "part of the design".
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel