Why do you say this is not the correct solution?

The registration of the Gcf.destroy method needs to only be done if the user is using pyplot.

On the other hand, this code path may be only accessed through pyplot so it is ok (and this relates back to my, @OceanWolf , and @fariza long running attempt to pull pyplot related code out of the backends).

Also because it has both name errors and just does not work as-is (I did this on the train and pushed when I hit the station).

Fixed and force pushed.

@tritemio Can you see if this fixes your problem? If you need this to work for a class very soon we can work out a monkey-patch recipe.

@tacaswell, thanks for fixing this. I have problems building matplotlib on windows. I tried to build a conda package from this recipe here, replacing the initial part of meta.yml with:

package:
  name: matplotlib
  version: 1.5fix

source:
    git_url: https://github.com/tacaswell/matplotlib
    git_tag: fix_nbagg_close

but it fails with:

C:\Users\laser2002j\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\xlocale(342) :
warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
c:\users\laser2002j\anaconda\conda-bld\work\src\ft2font.h(7) : fatal error C1083: Cannot open include file: 'stdint.h': No such file or directory
error: command 'C:\\Users\\laser2002j\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\\Bin\\amd64\\cl.exe' failed with exit status 2

Building from sources with python setup.py build fails becaus it cannot find freetype and libpng (that are installed through conda). I guess I will try under linux for now.

@tacaswell, I tested your patch on linux. It solves this specific problem, i.e. that no new figure is shown after closing a figure with the "x" button.

However, I have other issues with the notebook backend on multiple re-executions of the same cell containing a plot. I don't know if these issues are related. If not, I can move these to a new issue:

1. Procedural API: after the second execution of the same cell no figure is displayed (until the next close() call).
2. OO API: after each execution, the old fig and ax objects are overwritten, a new figure is created and the RAM is filled with invisible figures. Even plt.close('all') does not free any RAM.

Those should be new issues. They are related to the issue is the single
ton nature if the display area in the notebook and the way that ipython
captures refs to outputs.

On Fri, May 22, 2015, 18:29 Antonino Ingargiola [email protected]
wrote:

@tacaswell https://github.com/tacaswell, I tested your patch on linux.
It solves this specific problem, i.e. that no new figure is shown after
closing a figure with the "x" button.

However, I have other issues with the notebook backend on multiple
re-executions of the same cell containing a plot. I don't know if these
issues are related. If not, I can move these to a new issue:

Procedural API: after the second execution of the same cell no figure
is displayed (until the next close() call).
2.

OO API: after each execution, the old fig and ax objects are
overwritten, a new figure is created and the RAM is filled with invisible
figures. Even plt.close('all') does not free any RAM.

—
Reply to this email directly or view it on GitHub
#4456 (comment)
.

This needs to be merged soon.

I'm not 100% of the behaviour that is being targeted here. Is this fixing a bug, or changing the behaviour? If the latter, we certainly would want a UAT for this.

This needs to be merged soon.

I'm confident we can do this by next weekend - is that too late?

The problem is that when you hit the red 'x' the figure is closed on the js side, but not on the mpl side so plt.gca() still points to an axes which is not being displayed.

It looks fine to me now, MEP27 will fix this anyway, but as the main change occurs only in new_figure_manager_given_figure which MEP27 doesn't even use, and the only other change inCommSocket looks logical, something I will perhaps need for MEP27.

Note I say this having never worked with NbAgg, only WebAgg, but as far as I understand NbAgg just extends WebAgg...

This makes sense on first read and I definitely see the problem it's trying to address. But as the last "nbagg" expert I'll defer to @pelson for the final word on this one.

Coupled with #4841

There are two remaining subtle things

• make sure figures get closed on kernel restart (also does not happen in 1.4.3)
• still get a 'no such comm' error from closing figure programtically from python side

and updating the UAT

Great improvements. Do you want to fix the remaining issues on this branch before merging or do that in a new PR?

I noticed that the connection info in matplotlib.backends.backend_nbagg.connection_info() seems to be wrong in interactive mode enabled with the magic.

I.e. with one figure open and shown it reports the figure a pending show:

print(matplotlib.backends.backend_nbagg.connection_info())
Figure 1 - Figure 1
Figures pending show: 1

As far as I can tell it reports all figures as pending show in interactive mode. This is however not an issue with this branch but already happens on master.

In IPython/Jupyter 4 %matplotlib notebook raises a ShimWarning. We should probably import the comm from ipykernel if IPython 4 is installed.

/usr/local/lib/python2.7/site-packages/IPython/kernel/__init__.py:13: ShimWarning: The `IPython.kernel` package has been deprecated. You should import from ipykernel or jupyter_client instead.
  "You should import from ipykernel or jupyter_client instead.", ShimWarning)

I think both of those can be done in a different PR, but I want to update the UAT before we merge this.

I don't think that the connection_info is useful in interactive mode. It is looking at _pylab_helpers._activeQue which is a list of open figures which the 'active' one last. When a new figure is set active it is bubbled to the end. It looks like the point of this is so that when the user closes the active figure we can select the most recently active one (should probably implement this as a heap, but). In backend_nbagg.Show in non-interactive mode reaches is and removes the managers from _activeQue (which no other backend does) on show and then uses the length of _activeQue to determine how many figures are pending.

👍

This seems to have a bad interaction with some styles, but not all, where
it gets stuck in an infinite redraw loop.

On Sun, Aug 16, 2015, 9:08 AM Jens Hedegaard Nielsen <
[email protected]> wrote:

[image: 👍]

—
Reply to this email directly or view it on GitHub
#4456 (comment)
.

I can't reproduce the issue I was having on this branch, but saw it on a really hacked up branch (basically merged all the outstanding feature PRs) that I have a demo at pygotham off of.

UAT? What does that mean?

Does your (@tacaswell) comment about _pylab_helpers._activeQue, explain the "careful rebuilding of the activeQue" comment in _pylab_helpers?

User acceptance testing, In the notebook modified in the last commit

Looks like it now needs a rebase otherwise good

This is a conflict in the UAT, hurray!

I made an issue to track the remaining figure close issues above #4940

Thanks for taking care of the that issue.

On Mon, Aug 17, 2015, 12:45 PM Jens Hedegaard Nielsen <
[email protected]> wrote:

I made an issue to track the remaining figure close issues above #4940
#4940

—
Reply to this email directly or view it on GitHub
#4456 (comment)
.