need advice on gui thread

[dpn]

Hi all,

I am new to Qt/QThread.

What is the best way to handle Worker thread in GUI thread. Qt has GUI/Worker thread concepts?

I have to show progress on GUI while copying folder. Can somebody suggest in brief. It should allow to quit the program whenever I want to quit the application from context menu option.

Thanks

[ChrisW67]

There is no need for threads to display progress while you copy files. Have a look at QProgressBar: connect a signal emitted as files are copied to the setValue() slot of QProgressBar.

You can quit the program at any time by connecting a signal to qApp's quit() slot (see QCoreApplication::quit()).

[anda_skoa]

The program might need a thread to do the copying, e.g. if QFile::copy() should be used because that one is blocking.

In any case progress reporting works the same way: the code that copies emits progress signals, which are connected to a progress bar or progress dialog.

Cheers,
_

[dpn]

Hi,

I have goggled for qt worker threads. I am new to Qt. I found three kinds of implementations.

1. Inherit worker class from QThread and override Run()
2. Create QThread object as member variable of worker class
3. make it as a thread by using movetothread.

In which scenario, I have to use 1st approach. If possible, plz explain about other approaches.

Thanks in advance.

[toufic.dbouk]

class Worker : public QObject {
Q_OBJECT

public:
worker()//constructor
public slots:
void process(); // do your work here

signals:
void finished(); // emit when done
};

and connect it in a way similar to this:


QThread* thread = new QThread;
Worker* worker = new Worker();
worker->moveToThread(thread);
connect(thread, SIGNAL(started()), worker, SLOT(process()));
connect(worker, SIGNAL(finished()), thread, SLOT(quit()));
connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));
connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
thread->start();

That would be a good way of working with threads in Qt and its quit interesting and flexible and easy.
hope that helps Best Reagrds.

[anda_skoa]

I have goggled for qt worker threads. I am new to Qt. I found three kinds of implementations.

1. Inherit worker class from QThread and override Run()
2. Create QThread object as member variable of worker class
3. make it as a thread by using movetothread.


You have two options here: 1 and 3. 2 alone does not make the worker code execute in the second thread.



In which scenario, I have to use 1st approach. If possible, plz explain about other approaches.


The 1st approach is useful if the parallized operation does not need an event loop, e.g. some form of blocking loop.
The other approach is useful if you need an event loop.

Cheers,
_

[dpn]

Should application delete thread and worker objects?

[wysota]

Should application delete thread and worker objects?

The application should always clean up the mess it has done.

[high_flyer]

The real answer (to the original thread question), as most of the time is: "it depends".
On many things and considerations.
So a real "right way of doing it" is not something absolute.
Usually however, if you design your code well and in OOP way, what ever it is you want your worker thread to do should be encapsulated in a way which is not dependent (but capable) of running in a thread.
This usually will translate to NOT needing to subclass a QThread.
This issue got to be somewhat of a religious issue over the past years.
Different people just feel that one way is more right than the other.
The test is in the real word: which implementation fits your design the best way on all fronts:
readability, re-usability, maintenance (such the the open-close principal) etc.
Here is a interesting post by an (ex?) troll, where he answers another blog post (be sure to read it, its linked in the blog text!).
Once you have read it, make the best decision for your case.
And don't let anyone else tell you if its wrong or right, unless they can prove their claim with valid points to your specific case.
http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html