[PySide] Keeping GUI responsive

Israel Brewster ijbrewster at alaska.edu
Thu Dec 5 15:40:12 CET 2019

Keeping the application responsive *in general* is easy - just call Application.exec_(), and all is good - no need to break the application up, call processEvents(), zero second timeouts, etc - it works as expected. The only difficulty is this one function that is called at specific times in response to specific user actions.

That said, I *could* of course pepper said function with calls to Application.processEvents()…. but that’s generally a sign of a bad design, and would only work well if a) I get the calls the the right places, and b) there is no single third party function call (i.e. something that I can’t insert calls into) that takes a long time to run.
Israel Brewster
Software Engineer
Alaska Volcano Observatory 
Geophysical Institute - UAF 
2156 Koyukuk Drive 
Fairbanks AK 99775-7320
Work: 907-474-5172
cell:  907-328-9145

> On Dec 5, 2019, at 12:16 AM, Stephen Morris <stephen.morris at silvaco.com> wrote:
> I’m not sure if running PySide from a Python interpreter in another thread can ever work, since Qt itself will only run a GUI from the main thread, and in any case PySide appears to share the main QApplication with the C++ Qt GUI. So I’ve only ever managed to run a PySide GUI from the application main thread.
> There are two ways I know of to keep a single-thread process responsive, though both involve the long-running application being broken up in some way into discrete steps:
> Execute the application in a loop, with a call to QCoreApplication.processEvents() made in each iteration of the loop.
> Make the innards of the long-running application into a slot that is designed to be called multiple times, and set a zero-second single-shot timer to fire at the end of the slot function – connecting the resulting signal to the slot itself – so that the slot will be invoked another time once the timer “times out”. The trick to this is the fact that even a zero-second timer will have to wait while the event loop processes system messages (mouse-move events etc.), so that just like in suggestion (1) this allows user-system interactions to be processed before execution of the long-running function resumes.
> Stephen Morris 
> From: PySide <pyside-bounces at qt-project.org> On Behalf Of Israel Brewster
> Sent: 04 December 2019 23:41
> To: pyside at qt-project.org
> Subject: [PySide] Keeping GUI responsive
> I know this is a FAQ, however I haven’t been able to make any of the standard answers work for me. Here’s the situation:
> - using PySide2 5.12.2
> - I have an object (QMainWindow subclass) that contains most of the code for my application
> - One of the functions that runs in response to user input takes around 2 seconds to run. The GUI obviously freezes during this time (BAD!)
> - Said function needs to access and modify several large variables (pandas data frames) from the main object
> So here’s the problem: If I run this function as a separate (python) thread, that doesn’t help - the GUI is still frozen. I’m thinking this is due to the GIL, but I could be wrong about that. Running under the multiprocessing module, however, doesn’t appear to be an option due to the number and size of the data structures that the function needs to modify, and if I try just to see what happens, the process actually crashes.
> So what are my options here? How can I keep the GUI responsive while this function runs, without being able to spin it off as a separate process? Or is the only option going to be to completely rip apart the function and try to re-build it in such a way that it can, somehow, still access the memory from the main thread, while doing the processing in a separate function?
> ---
> Israel Brewster
> Software Engineer
> Alaska Volcano Observatory 
> Geophysical Institute - UAF 
> 2156 Koyukuk Drive 
> Fairbanks AK 99775-7320
> Work: 907-474-5172
> cell:  907-328-9145

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20191205/173b8cfd/attachment.html>

More information about the PySide mailing list