Any alternatives to QThread and QProcess for blocking operations in main GUI thread?

[mass85]

Then what is the right design pattern for thing as simple as opening of new window? Consider this code:

void MainWindow::keyPressEvent(QKeyEvent* keyEvent)
{
    if (keyEvent->key() == Qt::Key_F1)
    {
        HelpDialog help(this);
        help.exec();
    }
}

void MainWindow::keyPressEvent(QKeyEvent* keyEvent)
{
    if (keyEvent->key() == Qt::Key_F1)
    {
        HelpDialog help(this);
        help.exec();
    }
}

To copy to clipboard, switch view to plain text mode 

If in MainWindow you press quickly F1 three times, the first QKeyEvent will cause to exec HelpDialog, but the other two events will be handled in HelpDialog, which is totally unacceptable, because it may cause some random actions that user is not aware of. Please don't say that it is pointless to press one button three times and that noone will do it, because you can do it just by accident. But there is a better reason for doing such a thing than accident. When process of displaying new window lasts long (let's say 1s) user doubts if the keyboard/application detected if key had been pressed and then he presses it again.

[amleto]

statemachine. Like I already said, back in post 2!

for this simple example you would have three states.

1) waiting
2) starting
3) running

You can only go from state to state in order: 1->2->3->1 etc.

Default state is waiting. As soon as f1 is pressed, state is changed to 2). In state 2), keypress does nothing.

State 2 does the making of new form and exec(). As soon as exec is called, state is changed to running.

As soon as exec finishes, state changes back to 1.

[mass85]

If I understand your idea, you want to run exec in QThread. As far as I know QThread is just a worker thread and you cannot use any widgets in it.

[amleto]

No, it has nothing at all to do with threads. Where did I mention threads? I mentioned state machine, didn't I?

and you can 'use' any widget you want in a thread, but you can only make widgets in the main thread.

[mass85]

Then what is this state machine for? If you do this in main Gui thread you don't need to remember current state, everything happens consecutively like in my last example of code.

[amleto]

your code has a problem when user keep pressing buttons. using a statemachine can resolve this problem. Is that the third time I have said it now?

[mass85]

You are still not explaining how state machine could solve this problem.

I think you are missing the fact that generation and delivery of QKeyEvent does not happen in background. There is no concurrency between construction of window and delivery of QKeyEvents. Here is the flow:

1. QKeyEvent is dispatched to MainWindow.
--- in the background user presses another two keys ---
2. keyPressedEvent constructs HelpDialog.
3. New event loop is started by calling exec() on modal dialog.
4. In the new loop Linux keyboard driver's output buffer is checked and two new keys are found. (actually I'm not sur how it happens, that's one of the things I'm trying to figure out).
5. Two QKeyEvent objects are generated for both of new keys.
6. The first is dispatched to HelpDialog which has focus now.
7. Later the second one will be dispatched to widget with focus (who knows which).

This is how it works (more or less) in my system.

[amleto]

Sorry, for some reason I have been thinking that you had a problem with too many events sent to the main window.

Anyway, your problem is purely down the event handler (or something else on the main thread) taking up too much time. It is blocking the main thread from handling events quickly, and that is why a key press on mainwindow is getting delayed and sent to another window.

Move heavy work out of the gui thread - it should not be there anyway.