Closed mdickinson closed 1 year ago
Versions: Python 3.6.13 from EDM, Pyface 7.3.0-5, PyQt5 5.14.2-4, PyQt5-sip 12.7.2-1. I'll do some experimentation with other Qt wrappers.
This appears to be quite specific to the EDM runtime and Qt / PyQt versions.
I can reproduce with the following EDM combinations:
I haven't managed to reproduce at all with non-EDM setups. It looks as though this may be a Qt bug that's long since been fixed. As such, we probably shouldn't worry about this too much.
With the fixes made to TaskWindow closure in #1203 and changing the test method to connect to closure earlier:
def test_lifecycle():
window = TaskWindow()
window.open()
print(window.control)
window.control.destroyed.connect(report_window_destroyed)
run_event_loop_for_fixed_time(3.0)
window.close()
window.destroy()
run_event_loop_for_fixed_time(3.0)
(because QApplication.quit()
closes windows, and so control
gets set to None
) this no longer has the window open past the close()
- which becomes a no-op.
Quick update - it also works if you use app.exit
(which doesn't close windows) instead of app.quit
.
I think that that means that #1203 resolves this.
I'm seeing a situation in which a Pyface
TaskWindow
is still visible even after everything has been closed and shut down. At that point, there seems to be no evidence that the correspondingQWindow
object still exists in either the Python domain or the C++ domain.Here's a script to reproduce on my machine:
When I run this script, at the point where the script drops into the
pdb
debugger, the window is still visible (but not fully functional: it can't be minimised or closed, for example), but looking atgc.get_objects()
, I see no evidence of any Python-sideQObjects
still being alive, besides twoQApplication
objects.Exciting screenshot of a blank window: