Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

toggle between inline and floating figures #1927

Closed
anderwm opened this Issue Jun 12, 2012 · 18 comments

Comments

Projects
None yet
7 participants

anderwm commented Jun 12, 2012

I have looked quite hard for this ability and have come up empty, so forgive me if I am missing the obvious.

I like inline figures most of the time, but sometimes I want a particular figure in the matplotlib NavigationToolbar so I can zoom in and pan around. Is there a way to toggle between inline/floating figures while in a session?

Owner

minrk commented Jun 12, 2012

This is impossible, because once a matplotlib backend is selected, it can not change. You would have to restart the kernel and select a new backend with %pylab inline or %pylab osx.

The only reasonable solution to this is to use a GUI backend, and then inline figures explicitly with display(fig).

Owner

fperez commented Jun 12, 2012

I did have once code working for this very feature, which I wrote together with @jdh5238 back in India. But it's bitrotted and unmergeable right now, I'm afraid. We might get back to it at Scipy 2012: it's not really much or hard, just a little delicate and I haven't blocked the time to implement it.

anderwm commented Jun 12, 2012

At worst I guess i could pass it to another python session running a gui backend, how (in general) did you do it before?

I thought it would just be subclassing the NavigationToolbar and putting it into your inline backend_inline. I have done this in a stand alone gui, but not nearly on something of the scale of Ipython.

Owner

fperez commented Jun 12, 2012

It involved working directly with matplotlib under the hood to enable it to switch backends under certain conditions (such as transitions only being allowed between one gui backend and non-gui ones, and only one gui backend ever being initialized per the life of the session).

Owner

ellisonbg commented Jun 27, 2012

@fperez: that sounds fragile, no. The current solution (use a GUI backend along with display(fig)) is i) clean and ii) already implemented.

Owner

fperez commented Jun 27, 2012

Don't worry, it's not that bad. Don't diss it until you've seen the code :)

In terms of usability it really can make a huge difference, because the current situation forces you to restart the kernel if you started in inline mode and then need to do some interactive work with an image.

And trust me, it can be done without any problems. Just because a piece of code requires some care in writing doesn't mean we shouldn't have it. We wouldn't have written IPython otherwise :)

Owner

ellisonbg commented Jun 27, 2012

I admit, my imagination took over here, based on our broad experience in getting the GUI integration right (IE, it is really difficult). It sounds ugly, but I would love to be proven wrong :)

As a separate note, one thing we will need at some point is the ability to only allow the inline backend for situations where the notebook is running remotely.

Owner

fperez commented Jun 27, 2012

On Tue, Jun 26, 2012 at 8:02 PM, Brian E. Granger
reply@reply.github.com
wrote:

I admit, my imagination took over here, based on our broad experience in getting the GUI integration right (IE, it is really difficult).  It sounds ugly, but I would love to be proven wrong :)

No, this is really easier than the gui event loop work, it's just
forcing mpl to switch and keeping track of which gui we've
initialized, so that there's never more than one. With magics now
being clean objects that can keep the state they need, the
implementation can be done without ugly hacks.

As a separate note, one thing we will need at some point is the ability to only allow the inline backend for situations where the notebook is running remotely.

Sorry, don't understand what you mean here...

Owner

ellisonbg commented Jun 27, 2012

On Tue, Jun 26, 2012 at 8:11 PM, Fernando Perez
reply@reply.github.com
wrote:

On Tue, Jun 26, 2012 at 8:02 PM, Brian E. Granger
reply@reply.github.com
wrote:

I admit, my imagination took over here, based on our broad experience in getting the GUI integration right (IE, it is really difficult).  It sounds ugly, but I would love to be proven wrong :)

No, this is really easier than the gui event loop work, it's just
forcing mpl to switch and keeping track of which gui we've
initialized, so that there's never more than one.  With magics now
being clean objects that can keep the state they need, the
implementation can be done without ugly hacks.

As a separate note, one thing we will need at some point is the ability to only allow the inline backend for situations where the notebook is running remotely.

Sorry, don't understand what you mean here...

When a notebook is running on a remote system, you can't use a GUI
backend. Thus, we want the ability to start the notebook server and
disable all backends except inline. Probably want a nice clean
message, rather than an exception, something like:

"The XXX backend is not supported in this kernel, try %pylab inline"

Cheers,

Brian


Reply to this email directly or view it on GitHub:
#1927 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner

fperez commented Jun 27, 2012

On Tue, Jun 26, 2012 at 8:15 PM, Brian E. Granger
reply@reply.github.com
wrote:

When a notebook is running on a remote system, you can't use a GUI
backend.  Thus, we want the ability to start the notebook server and
disable all backends except inline.  Probably want a nice clean
message, rather than an exception, something like:

"The XXX backend is not supported in this kernel, try %pylab inline"

Ah, yes. Somehow I parsed your sentence as not allowing the inline
backend when running remotely, which I just couldn't understand. I
just misread it, thanks for clarifying. Indeed, a config flag that
bans the gui backends would be good to have.

Contributor

tkf commented Jul 5, 2012

It would be nice if you can choose matplotlib backend per IPython frontend. I guess it will be possible once matplotlib support dumping and loading figures, then you can send dumped figure via socket. But it seems there is no progress (matplotlib/matplotlib#323).

Owner

minrk commented Jul 5, 2012

Excluding the fact that kernels can be shared by multiple frontends, you can actually have different config overrides based on the frontend app that starts the kernel. When a kernel is started by an application, it always loads ipython_config, then it will load the parent's config file afterwards (ipython_qtconsole_config, ipython_notebook_config, etc.), which will override any defaults set in ipython_config.py.

Contributor

tkf commented Jul 8, 2012

Hi, I wrote a Python module to convert matplotlib figure to Chaco figure (https://github.com/tkf/mplchaco). Using this module, you can convert Matplotlib's inline plot into Chaco's GUI plot. So, basically you just need to do this when you want GUI plot::

%gui wx
fig = pyplot.gcf()
from mplchaco import mpl2chaco
mpl2chaco(fig).configure_traits()

I will play it with more and upload to PyPi if it is good.

anderwm commented Jul 11, 2012

@minrk For me, multiple frontends sharing a kernel but acting different is the awesome strength of Ipython. However, it seems that is exactly why this problem is bothersome...you can't tap into your already running session to explore a figure in closer detail.

Possibly I am flying solo here, but a typical use case for me goes:

Start an Ipython session ( in inline because I'm not sure what the result will be yet and don't want the clutter), import some data and manipulate it in various ways, plot it, hate it, filter it, plot it, repeat. Then eventually I realize I want to show off some figure I have inlined, so I have to either dump my history and run the whole thing in another kernel. Or save the data to file and reload it in another session.

Not a huge deal, but comes up quite often anyway.

Owner

fperez commented Jul 24, 2012

@anderwm, please test #2179 and let us know how it goes for you. That's precisely a re-implementation by @dopplershift that resuscitates the code I referred to above and completes things. We're almost ready to merge it, but one more pair of eyes on it would be good.

@fperez fperez referenced this issue Jul 24, 2012

Merged

Pylab switch #2179

anderwm commented Jul 25, 2012

So far this seems to work as expected, this is exactly the functionality I was looking for.

@anderwm anderwm closed this Jul 25, 2012

cpbotha commented Sep 9, 2013

I hope I'm allowed to add here that this is awesome (and something I've been hoping for for a long time), thank you very very much all!

Owner

Carreau commented Sep 9, 2013

Thanks, we always appreciate kinds words like that.
Wouldn't have been possible without the matplotlib guys (done durring scipy 12") , I've been using it for almost a year now and I tend to forget that it is "new".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment