Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | No because, depending on where you emit the signal your are
| > targetting
| > | this or that slot in particular.
| > But this is instances of signals, so you are emitting the signals in
| > the instance of the class that you are in. That is the whole point is
| > it not, the signal should not care or bother which slot will be called
| > as a result of a emmit.
|
| Year, that's the theory. In practice there is often a one to one
| relationship between signal and slots. It is nice anyway to know what
| impact _should_ have this signal in the dialog.
If that is so (1:1 relationshipe) and the signal and the slot is in
the same class (instance) then why use a signal in the first place?
Man I posed myself the same question when I read all the kernel code
using boost signals. Those can and should be cleaned out!
For the dialogs, that is another story though as dialog redrawings are
desynchronized and a single class can contain multiple independant
controls. So Qt signal/slots for dialogs make sense because they keep
the ui responsive in any case. But usage of signals should be reserved
to dialog communication and maybe also for forked process.
Abdel.
