Skip to content

Switching to inline backend closes GUI windows #15913

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

Closed
flutefreak7 opened this issue Dec 11, 2019 · 5 comments · Fixed by #26472
Closed

Switching to inline backend closes GUI windows #15913

flutefreak7 opened this issue Dec 11, 2019 · 5 comments · Fixed by #26472
Milestone

Comments

@flutefreak7
Copy link

flutefreak7 commented Dec 11, 2019

Bug report

Bug summary

When a plot is made with the qt5 backend on and then the backend is changed to inline, the active plot window(s) are closed. This makes it very difficult to switch cleanly between backends within a notebook. The two mediocre workarounds I can see are:

  • always specify the backend before plotting (since you can't automatically "switch back")
  • use plt.show(block=True) and switch back to inline after the user is done with the GUI figure. This has the downside of locking the Notebook execution while the figure is live.

Code for reproduction

The linked gist shows what I'd like to accomplish which is a context manager that enables matplotlib plotting in a GUI window from within a Notebook that is otherwise using the inline backend. Basically I want the notebook to use inline (for a variety of reasons), but I occasionally wish I could interact with the data in a separate figure.
https://gist.github.com/flutefreak7/65d824358122360911e2d4c43085007a

As a side note, easy switching between inline and notebook/widget backends would also scratch part of this itch, but the interactive notebook backends still don't enable full screen usage or easily throwing a plot on another monitor. ipyvolume has full screen figured out, so that seems doable.

Here's the context manager I wish worked:

# Paste your code here
@contextmanager
def window(block=False):
    %matplotlib qt5
    plt.ioff()
    yield
    plt.show()
    # The switch back to inline closes the qt5 plot
    plt.ion()
    %matplotlib inline

with window():
    plt.plot([1, 3, 2])

Actual outcome

The outcome of the above code is that a plot window flashes into existence for a split second, then is closed when the %matplotlib inline call is processed.

Expected outcome

It would be great if plots created with the qt5 backend could stay visible while other plots with the inline backend were also being created. If use %gui qt (to establish a reliable event loop) and create a bunch of Qt windows by other means, they live concurrently with the Notebook as long as the kernel is alive. I'd like matplotlib GUI figures to be able to live on regardless of the current backend.

Matplotlib version

  • Operating system:
  • Matplotlib version: 3.1.1
  • Matplotlib backend (print(matplotlib.get_backend())): inline and qt5agg
  • Python version: 3.7.3
  • Jupyter version (if applicable):
jupyter                           1.0.0
jupyter-client                    5.3.4
jupyter-console                   6.0.0
jupyter-contrib-core              0.3.3
jupyter-contrib-nbextensions      0.5.1
jupyter-core                      4.6.0
jupyter-highlight-selected-word   0.2.0
jupyter-latex-envs                1.4.6
jupyter-nbextensions-configurator 0.4.1
jupyterlab                        1.0.5
@jklymak
Copy link
Member

jklymak commented Dec 11, 2019

I don't really have a good feel for whether what you are asking for is possible or not, but have you tried the notebook backend, or the widgets backend? They seem suited to what you want to do.

@flutefreak7
Copy link
Author

I guess I have a few issues with notebook and widgets:

  • You can't easily switch between inline and notebook/widgets
  • Plots made with notebook/widgets don't have a good static representation in an exported copy of a notebook (like HTML) which I use to share work with non-devs
  • Plots made with widgets backend don't show up when a notebook is opened but hasn't yet been run (showing "Error displaying widget: model not found" instead of showing the plot as it was last generated) - this also affects visibility of plots in notebooks rendered on GitHub, GitLab, nbviewer, etc
  • Embedded plots can never use the whole screen or any of my extra monitors - a big part of why my team wants the ability to "pop-out" a plot into it's own window is so that it can be expanded to fill a monitor - possibly a different monitor than the one jupyterlab is in.

@jklymak
Copy link
Member

jklymak commented Dec 11, 2019

Just a note that notebook plots certainly have a static html, but agree that widget plots don't.

Fair enough about "pop-out" plots. Hopefully someone here can speak to how those work or if there is a workflow that can suit your needs.

@anntzer
Copy link
Contributor

anntzer commented Dec 12, 2019

See also #14471.

I think this should be doable (if the event loops are not compatible we error out anyways, but otherwise I don't see why we can't have e.g. qt5agg and qt5cairo windows coexisting)? Does simply removing the call to close("all") in the implementation of pyplot.switch_backend work for you?

If that works there's a reasonable way forward with the behavior change (of ultimately not calling close("all"): during the transition period, warn if any windows are getting closed and tell the user to call close("all") explicitly.

@github-actions
Copy link

github-actions bot commented Jul 3, 2023

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jul 3, 2023
@github-actions github-actions bot added the status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. label Aug 4, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 4, 2023
@tacaswell tacaswell reopened this Aug 4, 2023
@github-actions github-actions bot removed status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. status: inactive Marked by the “Stale” Github Action labels Aug 7, 2023
@QuLogic QuLogic added this to the v3.8.0 milestone Aug 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants