8000 Qt5 reset signals after non-interactive plotting by joelfrederico · Pull Request #13027 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Qt5 reset signals after non-interactive plotting #13027

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

Merged
merged 1 commit into from
Jan 4, 2019
Merged

Qt5 reset signals after non-interactive plotting #13027

merged 1 commit into from
Jan 4, 2019

Conversation

joelfrederico
Copy link
Contributor
@joelfrederico joelfrederico commented Dec 20, 2018

PR Summary

Non-interactive plots change the signal handler after they have been closed. They should reset it instead

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant

@joelfrederico
Copy link
Contributor Author

I'm not sure how to test this without actually opening a window. I need to fire a non-interactive plot in Qt5. I don't need it to actually draw, but I need to run show(). I think some other tests open windows, so perhaps this is okay?

@pytest.mark.backend('Qt5Agg')
def test_fig_close_ioff(qt_module):
# Turn off interactive mode
plt.ioff()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need this line for the tests to pass?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, yes. Otherwise plt.show() isn't a blocking call, which I think means that an entirely different branch of code is executed. The test would pass, but it wouldn't be testing the fix I made. But I'm working off of memory, I can double-check later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this really matters, but OTOH it probably doesn't hurt, so heh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that's true, it might be a no-op...

signal.signal(signal.SIGINT, CustomHandler)

# Show window- fires callback and exits
plt.show()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead show it may be more reliable to start the qt event loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did this in the new commit

@tacaswell tacaswell added this to the v3.1 milestone Dec 29, 2018
Copy link
Member
@tacaswell tacaswell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

provisional on making sure the tests run reliably.

@joelfrederico
Copy link
Contributor Author

Okay, now I'm done! Sorry @tacaswell, @anntzer for the multiple commits. This should be pretty thorough now, testing the signals during and after the event loop. I don't actually fire signals because Python doesn't let you fire SIGINT on Windows (see https://docs.python.org/3/library/os.html#os.kill). You can do it with win32api, but I don't want to create a testing dependency on pywin32.

@@ -114,6 +114,53 @@ def test_fig_close(backend):
assert init_figs == Gcf.figs


@pytest.mark.backend('Qt5Agg')
def test_fig_close_ioff(qt_module):
8000 Copy link
Contributor
@anntzer anntzer Jan 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename the test perhaps? Right now the name seems unrelated.
Except for that, can be merged.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, renamed.

@anntzer
Copy link
Contributor
anntzer commented Jan 4, 2019

Do you want to squash the commits? up to you.

@joelfrederico
Copy link
Contributor Author
joelfrederico commented Jan 4, 2019

Um... sure. It's cleaner, why not.

Edit: also rebased to master.

@anntzer anntzer merged commit f9c06a4 into matplotlib:master Jan 4, 2019
@joelfrederico joelfrederico deleted the qt5-reset-signals branch January 4, 2019 20:36
@tacaswell
Copy link
Member

Thanks @joelfrederico !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0