The canonical way to use a QTimer in a separate thread - c++

Question

I am tying to create a worker thread that will update a QTWidget at 1 second intervals (think of it as a digital clock or a progress bar updater might be a better analogy given the application).
My application is avionics specific that computes flight tracking info over a flight path and updates a map or some other QT widget regularly during the progress of the flight at 1 sec intervals (I suppose you could think of it as a sort of progress bar - where the progress bar could be replaced by a map or table widget in my case). The thread will probably take about 10-20 seconds to compute the entire flight data - (however it will have its first results available almost immediately) - these results need to be sent at 1 second intervals to the GUI to update the position of an aircraft on a map.
There is a lot of confusion about the right and wrong way to incorporate a timer that updates a worker thread. The best source of knowledge I found was a QtCon talk entitied Multithreading with Qt - Giuseppe D’Angelo - it seems that the preferred method is to have a worker QObject that does not subclass a QThread and that has the timer running in its own event handler - but there is a lot of confusion about moving the worker thread to another thread that I don't understand very well and I am looking for some canonical advice on how to do this right. Doing so in a Lambda would be ideal as I could keep the logic and threading relatively isolated which would be ideal.
I am looking to see if someone could point me in the direction of a similar example (especially if it uses modern Lambdas). I am currently using QT 5.11.2.
My worker object (which contains the QTimer is as follows):
class SimulatedFlightWorker : public QObject
{
Q_OBJECT
public:
explicit SimulatedFlightWorker()
: mpMMRFlightData{}
{}
public slots:
// worker thread slot that computes the mpMMRFlightData
void importSimulatedFlight(
const QString& fileName,
const int aPlaybackSpeed);
void updateGUI(int secondsElapsed);
signals:
// every second during the flight we need to send a new MMR
// record to the GUI - to display on a spreadsheet or google map
void updateFlightData(const MMRTimedRecord& rMMRRecord);
// this is effectively when the worker thread is done
void flightCompleted();
private:
QTimer mTimer;
// the
std::unique_ptr<MMRFlightData> mpMMRFlightData;
};
This is the code where I setup the signals and slots (not working yet)
// Experimental worker model adapted from YouTube tutorial
// by Giuseppe di Angelo https://www.youtube.com/watch?v=BgqT6SIeRn4
auto thread = new QThread;
auto worker = new SimulatedFlightWorker;
connect(thread, &QThread::started, worker, &SimulatedFlightWorker::importSimulatedFlight);
connect(worker, &SimulatedFlightWorker::flightCompleted, thread, &QThread::quit);
connect(thread, &QThread::finished, worker, &SimulatedFlightWorker::deleteLater);
worker->moveToThread(thread);
thread->start();

Answer 1

It’s really simple:
Your calculations are done in a QObject-derived class
Updates are issued via a signal in that object.
Calculations are done in small chunks that take 10-20ms.
The calcualtions are triggered from a zero-duration timer – it’s not a timer, but a way of detecting event loop idle state in a thread.
The updates are triggered from a 1-second timer.
This class can be run on any thread — it will even work on the GUI thread, but will make it a bit less responsive (but not at all unresponsive).
You’d normally instantiate the class, start computations, and move it to a dedicated thread.