PySide / Python GUI hangs
I am currently writing a GUI for rvplayer that will allow artists to automatically display daily posts with slate and record information. The GUI is written with PySide and written in Python 2.7. My problem is when calling my process and updating mine QProgressBar
with stdout the GUI hangs. I know this is a common problem and that it can probably be solved by processEvents()
some means, but I know too little about threads and process loops to figure this out. Since my code is already a bit long, here is the part that is causing the problem:
def rv(self, args):
p = subprocess.Popen(["C:/Program Files/Tweak/RV-4.0.10-64/bin/rvio_hw.exe"]+[x for x in args], stdout=subprocess.PIPE)
while True:
line = p.stdout.readline()
if line != "":
progressStr=re.search(r"([0-9]+.[0-9]+%)", line.rstrip())
if progressStr == None:
print line.rstrip()
else:
progressInt=int(float(re.sub("[^0123456789\.]", "", progressStr.group())))
self.prog_QProgressBar.setValue(progressInt)
print progressStr.group()
else:
break
and here is the part that runs mine QApplication
:
if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)
finalForm = MainWindow()
finalForm.show()
sys.exit(app.exec_())
I call the rv function when a button is clicked, and although the progress bar keeps updating normally, the window starts unresponsive after a while. I don't understand at what point I could use app.processEvents()
to tell my QApplication to start a process in a separate thread or in the background.
source to share
Since it looks like you are not using threads, perhaps all that is required is to call processEvents
after the progress bar has been updated, e.g .:
self.prog_QProgressBar.setValue(progressInt)
QtGui.qApp.processEvents()
However, the effectiveness of this may depend on how long the process takes to get the result. All the call makes processEvents
is to immediately handle any pending events (such as drawing a widget, mouse clicks, etc.) that are currently in the application's event queue. In between these calls, the GUI will continue to freeze (i.e. the executable code does not run on a separate thread or in the background as you suggested). Thus, the extent to which this method can maintain GUI responsiveness depends on how often processEvents
it can be called in the method rv()
.
source to share
The problem is that it is not as if your application was frozen, but Windows thinks the application is frozen because it ignores events (mouse, click, etc., etc.), so Windows in its wisdom gives you this dialogue.
You need to start the thread after show () and then run the processEvents function and obviously only call sys.exit after the thread finishes.
source to share