https://bugs.kde.org/show_bug.cgi?id=411291
--- Comment #2 from Mark <mark...@gmail.com> ---
(In reply to Kai Uwe Broulik from comment #1)
> Obvious solution: listEntries handling in a thread in SlaveBase :P
Exactly my thought!
And i actually have a threaded version - somewhat - working here locally, but
that on it's own has some issues.
- SlaveBase doesn't inherit from QObject
- Due to above: no signals/slots directly
I can still work around that. Just make a QThread in which a QTimer lives that
does the 300ms interval. Something like:
QThread *timerThread = new QThread(nullptr); // no No slavebase as parent, no
QObject
QTimer *timer = new QTimer(nullptr);
timer->moveToThread(timerThread);
That very timer should be started when the listEntry objects start flowing in
and stopped when finished() is called.
And that's where i am right now with another issue. In the approach from above
the QTimer lives in another thread context. Aka, you cannot call _any_
functions on it from within SlaveBase. No start, stop, isActive, ...
I am, right now, managing to start the timer like so:
QObject::connect(timerThread, &QThread::started, [this]() {
timer->start();
});
Note: the "this" is "SlaveBasePrivate", the timer and timerThread objects live
in the SlaveBasePrivate scope.
Do you have any idea how to start/stop a timer that lives in it's own QThread
but start/stop them from within SlaveBase without signals?.... ;)
--
You are receiving this mail because:
You are watching all bug changes.
