Using QThread with minimal usage of signals/slots

[Preston_H]

Hello forum,

I'm using the Qt thread environment and got a simple program to work following some examples on the web that use the standard signals/slots approach to threading (example). The problem is that I am personally averse to using Qt's signals and slots in my programs, using them only when they are really necessary. More specifically, I am trying to keep signals/slots confined to the MainWindow class only. My reasoning for this is that I want my Qt applications to keep the UI fundamentally separated from the rest of the program; basically, make the Qt and C++ parts work as independently as possible.

Anyways, motivation aside my goal is to create a threading environment that will run an infinite loop and allow the user to control the UI simultaneously. And, I would like to do this without the standard signal/slot approach. I've come up with something (below link) that I think should work, but isn't.

Here's what I have so far.

Conceptually I think my code should achieve the same result as the signals/slots method, but it doesn't seem to be working. Specifically, I can get the routine to run, but while it's running my UI is locked out just like in any un-threaded function call.

Any advice?

Thanks!

[SGaist]

Hi and welcome to devnet,

No your code doesn't. What is currently happening is that you are moving your object to the new thread. Start the thread and then block everything with your while loop.

See QThread's documentation to see how you can use it with both a worker object or by reimplementing the run method.

Out of curiosity, why do you want to keep signals and slots confined to your GUI ? The concept is not attached to it at all.

[Preston_H]

Hi, and thanks for the welcome and the response.

@SGaist said:

No your code doesn't. What is currently happening is that you are moving your object to the new thread. Start the thread and then block everything with your while loop.

I agree with the first two parts. The last part I don't understand. Don't I move the object to the new thread and call thread->start() so that the while loop DOESN'T block everything? Fundamentally I don't understand how this is different than the signals/slots approach. I'm basically just manually connecting the function calls rather than using signals/slots, which automatically make those calls via the observer pattern it employs (emit signal, receive signal).

Out of curiosity, why do you want to keep signals and slots confined to your GUI ? The concept is not attached to it at all.

I have a hard time rationalizing this myself and I know it's somewhat arbitrary, but I'll do my best to explain. Basically, I want to use the functionality that Qt offers only when it is absolutely necessary. Signals/slots are an example of this. As far as I can tell, the signals/slots system is just an implementation of the observer design pattern that lets various components communicate with each other. The thing is, I'd like to program those communication channels myself if possible, mostly for educational purposes. I recognize how useful the Qt framework is, but I'd like things to be built from scratch as much as possible right now.

Now, in terms of GUI, it's absolutely necessary for me to rely on signals/slots since there would be no way for me to manually program, say, how a button being pressed should work. In fact, prior to looking into QThreads I considered first trying to do this only with the thread functions in the C++ standard, but since the program I'm writing this for is supposed to work cross-platform, it would be much harder to do without Qt.

[SGaist]

QThread::start will call run which default implementation starts a QEventLoop. What you do is call a function of an object in another thread which contains a blocking loop. You're calling it from the main thread, thus blocking it.

Then you should take a look at Qt's sources if you want to see how this is implemented rather than re-invent the wheel even for educational purpose. Each platform has it's own way of doing it and since your app is going to be cross-platform, you are going to hit problems that have already been solved in Qt.

Don't get me wrong, I acknowledge your thirst of knowledge, but it's not always for the best to write everything yourself from scratch when there are good and working tools.

[Preston_H]

Yep, you've helped me realize that this is one of those cases where it's not worthwhile to reinvent the wheel. Thanks for your help!