-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use QMainWindow.closeEvent for close events #1498
Conversation
The current code uses the QWidget.destroyed signal to emit a close event into matplotlib. This is a very bad idea, as it is a heavy abuse of Qt functionality. When a main window is closed in Qt, it and its children are deleted if the DeleteOnClose flag is set (which we did set). This causes the QWidget.destroyed signal to be called. Setting the DeleteOnClose flag is a very bad idea, since objects should only be deleted by the garbage collector. Soon after, PyQt4 will complain that "the underlying C++ object has been deleted", since the object is alive for python but dead for C++. This patch changes the machinery to use the QMainWindow.closeEvent to emit a close_event, which is what one actually wants.
Who's our resident Qt4 expert these days? @ddale? git blame shows a lot of people involved. I don't feel terribly qualified to assess whether this change makes sense. |
This might actually resolve a race condition I have seen when closing an animation with the Qt4 backend. I am not qualified to assess the correctness here, but @dopplershift might be. |
I'll claim expertise with C++ Qt4, but not so much expertise in either Qt4 with Python or, more importantly, our (ab)use of it (though I hope to rectify that in the somewhat near future) I will say that this commit seems to clean things up. However, I'm not using the GUI backends on a common enough basis right now to give it a good shakeout. |
use QMainWindow.closeEvent for close events
use QMainWindow.closeEvent for close events
One (possibly too late) concern is that this completely shadows the |
@tacaswell: That's a good point. As I'm not a Qt expert, can you propose a fix -- ideally with a standalone test -- in a new PR? I'll go ahead and file a new issue for it so it doesn't get lost, in any event. |
Gcf when it is closed. In PR matplotlib#1498 the attribute WA_DeleteOnClose was no longer set on the QtMainWindow object in QtFigureManager. The signal connection that was being used to remove the figure from Gcf when the window was closed was tied to the `destroyed()` signal of QtMainWindow, which is no longer being destroyed. Thus, gca and gcf would return references to no-longer visible figures/axes. _widgetclosed is now called when MainWindow emits 'closing()'.
Gcf when it is closed. In PR matplotlib#1498 the attribute WA_DeleteOnClose was no longer set on the QtMainWindow object in QtFigureManager. The signal connection that was being used to remove the figure from Gcf when the window was closed was tied to the `destroyed()` signal of QtMainWindow, which is no longer being destroyed. Thus, gca and gcf would return references to no-longer visible figures/axes. _widgetclosed is now called when MainWindow emits 'closing()'.
The current code uses the QWidget.destroyed signal
to emit a close event into matplotlib. This is a very
bad idea, as it is a heavy abuse of Qt functionality.
When a main window is closed in Qt, it and its children
are deleted if the DeleteOnClose flag is set (which we
did set). This causes the QWidget.destroyed signal to be
called. Setting the DeleteOnClose flag is a very bad
idea, since objects should only be deleted by the
garbage collector. Soon after, PyQt4 will complain
that "the underlying C++ object has been deleted", since
the object is alive for python but dead for C++.
This patch changes the machinery to use the
QMainWindow.closeEvent to emit a close_event, which is
what one actually wants.