On Monday, 5 August 2013 18:34:04 CEST, Kevin Krammer wrote:
Such code will work flawlessly for them but not for others, increasing
the
test matrix.
Understood, you guys have a good point -- thanks.
This is disconnecting everything connected to any signal of that job.
Did
you mean to disconnect(job, 0, this, 0)?
I think this is to protect against stop() emitting any signals. Probably
easier to call job->disconnect();
Or avoiding sigals in stop().
I was thinking about another valid use case, something watching for object
deletion. IMHO it's concievable to have a monitor of all pending jobs which
listens for QObject::destroyed(QObject*). This disconnect will suddenly
break this use case.
I was worried that this might even break QPointer, but it turns out that
it's using a completely different mechanism than signals/slots
(QObject::addGuard). I learned yet another new thing today -- cool. Anyway,
I'm not sure whether this is usable for the monitor use case.
Why is there the need to mute the signals anyway?
- WITH_KDE cannot supported with Qt5.
Not yet :)
But yeah, that will be a while :)
Yep, I meant "for now" :).
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
