Help with understanding QFutureWatcher::progressTextChanged(const QString & progressT

[d_stranz]

I was curious about this, so I spent a good hour yesterday going through the source code for QtConcurrent and I still have no clue how you can create a process that will send text update signals. What I learned was that these signals originate deep in the bowels of QtConcurrent as customized QEvent events, namely a QFutureCallOutEvent derived type, which internally contain a flag the describes a specific sub-type of the event - start, progress, finished, etc. QFutureWatcher, with the help of a few other internal classes, maps these events onto signals.

These events are generated by the QtConcurrent thread execution mechanism which iterates over the list of things you want to process and which posts these events at various points. I could not find a case in the distributed Qt source code where the thread execution mechanism posts an event containing text. There is a setProgressValueAndText() method in one of the thread control classes, but the only place where I can find this being called is by another method, setProgressValue(), which simply calls it with an empty string. The QFutureWatcher::progressText() method seems to be an unused placeholder in case you want to go to the effort of actually implementing something that uses it.

There are a dozen or more internal ordinary and template C++ classes that implement the QtConcurrent framework. The only way I can imagine implementing something that could also send text events would be to either derive from or implement a new thread execution iterator that could create text-containing events in addition to the normal numeric-only update events. And even then, I don't know how you would interface a process to this mechanism to relay process status. Even in the standard framework, the processes being threaded do not talk to the QtConcurrent framework. It is the thread execution iterator that sends these events based on where the iterator is in processing the list of things to do.

Most of the discussion I have seen around this online say to implement your own set of signals if you need something that the standard QtConcurrent framework doesn't provide.