PySide (Qt) event loop seems stopped when main window offscreen

41 views Asked by At

We have a PySide (Qt) application that has a main window, and also does I/O to other parts of our system. In particular, we have QThreads that receive messages from other applications; these threads then immediately emit signals that are picked up by main-thread objects to let them know that it's time to take action, and these "actions" sometimes are messages sent out to other applications on the system. We do this to simplify threading - the worker threads do nothing but detect that action must be taken, then all actions are done by the main thread.

One problem we have is that when the main window is not visible, usually because we switched to another virtual terminal, none of this happens. It seems like Qt halts event processing until we switch back to the terminal with the main window. When we switch back, suddenly all the events happen rapidly. I assume that this is an optimization of some sort, where Qt figures "The main window isn't visible, so we'll just stop until it comes back." Our application needs to continue processing events event when the main window is not visible.

I searched the QApplication, QObject, and QEventLoop documentation for information on this but didn't see it. How do I tell Qt to keep the events happening? Thanks.

1

There are 1 answers

3
Bill Shubert On

We now know why it is happening, and there probably is no solution. It's not the window being offscreen - it's how we put it offscreen. When we switch to another virtual terminal (this is on a raspberry pi, if that matters), the X server for the not-visible screen freezes. So our application runs happily along until it needs to draw something on the screen, then it tries to talk to X, gets no answer, and freezes, waiting for X to answer. If we shut off the timers that make us do occasional screen updates, then the problem goes away. If we stay on the same virtual terminal but hide the application in other ways, it keeps running.

Probably is no solution - the X server most likely needs to halt when it's virtual terminal isn't onscreen, and the application must update the screen periodically. At least we know why it is happening now.