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.mor...@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-boun...@qt-project.org> On Behalf Of Israel Brewster > Sent: 04 December 2019 23:41 > To: pyside@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
_______________________________________________ PySide mailing list PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside
