Qt apps basic functionality

tomy

Hi all,

Here in this Fortune Client example we have main.cpp as follows:

#include <QApplication>
#include "client.h"

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    QApplication::setApplicationDisplayName(Client::tr("Fortune Client"));
    Client client;
    client.show();
    return app.exec();
}

No supplementary thread is created in the project and by default we have the main thread for the GUI part, and the worker thread for the processes and computations, right?

Is it right the the main thread starts by client.show(); and the worker thread by app.exec();?

JKSH

@tomy said in Qt apps basic functionality:

QTimer postpones the execution of the method inside it (requestNewFortune), until all next lines inside the function (void Client::readFortune()), are executed. And then at the end when there is no line to execute, QTimer calls its function. Right?

Almost right.

QTimer does not call requestNewFortune(). QTimer puts requestNewFortune() in the event loop.

The event loop calls the requestNewFortune() after readFortune() finishes all its lines and returns.

@tomy said in Qt apps basic functionality:

This means requestNewFortune() will be executed some time later, when all other previous event in the QEventLoop have been executed.

This is on the contrary to the code @JKSH offered above, because there, the function inside the QTimer is called when all other next lines are called.

@KroMignon's description matches the code that I wrote. It is not contrary.

The sequence is this:

The event loop calls f1(). f1() starts running, so it blocks the event loop.
The QTimer in f1() puts triggeredFunc() in the event loop queue.
f1() prints "Hello".
f1() returns. The event loop can now proceed to the next task.
The event loop checks its queue. It sees triggeredFunc() in the queue, so the event loop calls triggeredFunc(). triggeredFunc() starts running, so it blocks the event loop.
triggeredFunc() prints "World".
triggeredFunc() returns. The event loop can now proceed to the next task.
The event loop checks its queue. If there is nothing in the queue, the event loop waits for the next event.

With f2(), the sequence is this:

The event loop calls f2(). f2() starts running, so it blocks the event loop.
f2() calls triggeredFunc() directly. triggeredFunc() starts running, so it blocks f2().
triggeredFunc() prints "World".
triggeredFunc() returns. f2() can now proceed to the next line.
f2() prints "World".
f2() returns. The event loop can now proceed to the next task.
The event loop checks its queue. If there is nothing in the queue, the event loop waits for the next event.

JonB

@tomy
Don't really understand what your question is here? I had a glance at that code, there are no "suplementary" threads, there is no "worker" thread. There is just one main process with one thread: it will do the GUI (during app.exec()), meanwhile (in the same one thread) asynchronous calls receive data from the server. The client do not block the client: they use signals & slots to handle data when it arrives. client.show() shows the dialog on the main thread, and app.exec() (also on the main thread) allows the Qt main event loop to run to interact with the dialog.

Does that explain?

tomy

@jonb

The main thread is accountable for GUI; the worker thread is accountable for the computations.
https://doc.qt.io/qt-5/thread-basics.html

Christian Ehrlicher

@tomy said in Qt apps basic functionality:

the worker thread is accountable for the computations.

But the Fortune Client Example does not use any thread apart the main thread - so what's your question?

tomy

@christian-ehrlicher

I believe the questions are asked clearly in the question body on top!
Where does that main thread start from, in the main.cpp?

What's the difference between client.show(); and app.exec();?

Christian Ehrlicher

@tomy said in Qt apps basic functionality:

Where does that main thread start from

The main thread is started from the OS when it executes the executable. So it's already there when main is called - in which thread should run main() otherwise?
What you maybe want to know is when the main Qt eventloop is started. But this is clearly stated in the QCoreApplication::exec() documentation.

SGaist

Hi,

The show method just schedules the fact that a graphical object should be shown. As @Christian-Ehrlicher pointed, the exec call starts the Qt event loop.

tomy

@christian-ehrlicher

But the Fortune Client Example does not use any thread apart the main thread - so what's your question?

So if there were any other thread it should have been declared using QThread, and since there is no such a line, we only have the main thread in that project. Right?

stated in the QCoreApplication::exec() documentation

in QCoreApplication::exec() documentation, it says:
To make your application perform idle processing (by executing a special function whenever there are no pending events), use a QTimer with 0 timeout. More advanced idle processing schemes can be achieved using processEvents().

That QTimer is also used in the following function of the project:

void Client::readFortune()
{
    in.startTransaction();

    QString nextFortune;
    in >> nextFortune;

    if (!in.commitTransaction())
        return;

    if (nextFortune == currentFortune) {
        QTimer::singleShot(0, this, &Client::requestNewFortune);
        return;
    }

    currentFortune = nextFortune;
    statusLabel->setText(currentFortune);
    getFortuneButton->setEnabled(true);
}

I think the function requestNewFortune will be called when there is no pending events. But what does that mean in practice?
We have a number of instructions above and below that line!

SGaist

No, the call is queued to be run at the first occasion.

The rest of the method might generate other events to be processed by the event loop but it's not the case for all lines.

tomy

@sgaist
The subject is still ambiguous for me! :| Probably if the questions below get answered I will figure out the case.

What are the events which are handled by the Even Loop in the method above (Client::readFortune())?
How are they handled/carried out? One after another, in order, from top ( in.startTransaction();) to down (getFortuneButton->setEnabled(true);)?
Where/When is that first occasion the call to the method in QTimer is run?

mrjj

Hi

What are the events which are handled by the Even Loop in the method above (Client::readFortune())?

the network class readyRead() signal is connected to Client::readFortune() so when
data comes, the signal is emitted and this function called.

How are they handled/carried out? One after another, in order, from top ( in.startTransaction();) to down (getFortuneButton->setEnabled(true);)?
Yes, line by line.
the use of the QDataStream transaction is explained in the docs.
https://doc.qt.io/qt-5/qtnetwork-fortuneclient-example.html
Basically it is used to ensure we get all data since the network sends data in thunks.
Its explained in detail under the function in the sample>
Where/When is that first occasion the call to the method in QTimer is run?

When user clicks the button the process is started by calling requestNewFortune

connect(getFortuneButton, &QAbstractButton::clicked,
this, &Client::requestNewFortune);

The requestNewFortune will make the network send the readReady signal which calls
readFortune which will then call the timer when the if is true.

tomy

@mrjj
Thank you for your time, but these were not what I was hoping to reach!
To summarise, I don't want to delve into the entire project to figure out the whole process; I got bogged merely down in that QTimer line and what it does and why it's necessary.
The full project is pretty straightforward and mostly worry-free to pursue.

Stating from question #1, supposedly the whole void Client::readFortune() function is one event. The instructions inside it are commands to be accomplished, one of which is the line QTimer::singleShot(0, this, &Client::requestNewFortune); we want to concentrate.

I surmise, requestNewFortune within the timer, is called when the event loop is idle and they're no pending events. That is, it will be called after all when nothing is waiting to be performed. Right until here?

Hence, I deduce that requestNewFortune within the timer is called at the end of the function, after executing the last expression getFortuneButton->setEnabled(true);.

I'm not sure if my thoughts are right and won't be astonished if you totally disagree! :)
but, at least, you know what the issue is I'm talking about.

KroMignon

@tomy I don't really understand what problem you are talking about.

This program is relativ simple to understand:

There is only 1 QThread, which is created/assigned by creating QApplication . There is no other thread.
This QThread has a message queue / QEventLoop instance which will wait until signals are emitted. Each stored message will the be executed in the same order as they are been received
By calling client.show(), the QDialog class will emit some signals, which are store in the main event loop
By calling app.exec(), the QEventLoop processing is started. And the stored signals in main event queue will be executed.
The main thread will ends, when the main event loop is stopped.

There is no magic nothing really complicated to understand.

Take a look at QThread documentation for more details

tomy

Just reread my prior post!!
My question is about QTimer mostly! I think I said that clearly.

Let me ask that, another way: what is the difference between QTimer::singleShot(0, this, &Client::requestNewFortune); and calling requestNewFortune() directly without the timer?

mrjj

@tomy
Hi
Yes there is.
The Qtimer puts on the event queue and will be called later meaning
the execution continues to the next line.

Calling the requestNewFortune will happen right now and the next line is not processed before this function ends.

JKSH

@tomy said in Qt apps basic functionality:

what is the difference between QTimer::singleShot(0, this, &Client::requestNewFortune); and calling requestNewFortune() directly without the timer?

Here is a simple illustration:

void triggeredFunc()
{
    qDebug("World");
}

void f1()
{
    QTimer::singleShot(0, &triggeredFunc);
    qDebug("Hello");
}

void f2()
{
    triggeredFunc();
    qDebug("Hello");
}

Assuming that your application has an event loop,

If you call f1(), your debug output will print "Hello" before "World".
If you call f2(), your debug output will print "World" before "Hello".

KroMignon

@tomy As try to explain to you calling QTimer::singleShot(0, this, &Client::requestNewFortune); will post event into the QEventLoop of the QThread used by this.
This means requestNewFortune() will be executed some time later, when all other previous event in the QEventLoop have been executed.
This also ensure, requestNewFortune() will be executed in the thread on which this is running.
And, to be exhaustive, requestNewFortune() will be executed, when attached Thread has an QEventQueue and the thread is running.

tomy

@mrjj
I'm confused by what you said.
You firstly say QTimer will be called later. Then you say, calling the function will happen right now!

@JKSH

If you call f1(), your debug output will print "Hello" before "World".

So, apparently my first assumption mentioned here more than one time was correct. That is, that QTimer postpones the execution of the method inside it (requestNewFortune), until all next lines inside the function (void Client::readFortune()), are executed. And then at the end when there is no line to execute, QTimer calls its function. Right?

@KroMignon

This means requestNewFortune() will be executed some time later, when all other previous event in the QEventLoop have been executed.

This is on the contrary to the code @JKSH offered above, because there, the function inside the QTimer is called when all other next lines are called.

The subject presumably is not that convoluted but I don't know why I understand your posts differently! :(

mrjj

@tomy said in Qt apps basic functionality:

You firstly say QTimer will be called later. Then you say, calling the function will happen right now!

Ok let me make it clear.

QTimer::singleShot(0, this, &Client::requestNewFortune); ---> later called

requestNewFortune(); ---> called right here. right now.

And in this context. Later means when event loop gets around to it.

KroMignon

@tomy said in Qt apps basic functionality:

This is on the contrary to the code @JKSH offered above, because there, the function inside the QTimer is called when all other next lines are called.
The subject presumably is not that convoluted but I don't know why I understand your posts differently! :(

Dear @tomy, it seems my explanation are not that clear as I supposed. So I do another try:

QThread owns a QEventLoop
When starting a QThread, the thread will wait until a new event is stored in the event loop, take it and execute the function with the attached parameters
When calling QTimer::singleShot(0, this, &Client::requestNewFortune);, what happen is that a temporary QTimer instance is created and started. When the passed delay is elapsed (in this case 0 milliseconds), the function/slots (in this case &Client::requestNewFortune) is stored in the event loop from the thread used by the receiver QObject instance (in this case this)

I think I can't explain it more clearly and hope now you have understand the difference between QTimer::singleShot(0, this, &Client::requestNewFortune); and calling directly requestNewFortune().