Skip to content
This repository

matplotlib macosx windows don't respond in qtconsole #640

Closed
claumann opened this Issue July 29, 2011 · 15 comments

3 participants

Chris Laumann Min RK Guillaume Calmettes
Chris Laumann

Running 0.11 rc1 and rc4, I can use the osx backend to plot (in new figure windows) but the windows do not respond to mouse clicks or any gui events. Is this my fault or something to be fixed?

Min RK
Owner
minrk commented July 29, 2011

Are you using --pylab or --pylab=osx? The OSX native backend eventloop doesn't get polled when run in a non-interactive process (as opposed to in a Terminal), so you must use '--pylab' mode for it to work.

Chris Laumann

Using:

ipython qtconsole --pylab

Then in the qt console:

x = r_[0:2*pi:100j]
y = sin(x)
plot(x,y)

A new figure appears in an osx window (using osx backend) but no events work on it (can't close, resize, use bottom toolbar, etc).

Min RK
Owner
minrk commented July 29, 2011

hm, what version of matplotlib?

I'm using master, and it's perfectly responsive.

Chris Laumann

I'm using enthought's latest distribution which has MPL 1.0.1 along with ipython 0.11rc1 (which I updated to rc4). I also can't use pylab=qt because it complains I don't have PyQt4.

Min RK
Owner
minrk commented July 29, 2011
Chris Laumann

I upgraded to 0.11, still using standard Enthought install otherwise and still the osx backend is not responding.

Chris Laumann

And now I've just compiled the master branch of matplotlib (1.1.0) and it still doesn't work. Doesn't seem to be an MPL thing. BTW, i'm on Lion. Any more debugging I can try?

Min RK
Owner

Hm, this is troubling. I, too, am running Lion and the OSX backend with the qtconsole with some regularity. There's some chance that it's EPD that's causing the trouble, but I don't see how.

Can you post some of the startup output of ipython qtconsole --debug --pylab (up to, but not including the first huge message)?

I think this behavior is exactly what happens when you use the OSX backend without launching IPython in pylab-mode, but I'm not sure how that would be happening.

Chris Laumann
Guillaume Calmettes

I have the same issue.

  • Launching ipython (without qtconsole) works fine (by using the Agg or osx as Backend for matplotlib).
  • Launching ipython qtconsole works fine only with --pylab=inline or --pylab=qt tags. If the --pylab=osx is specified, when I want to plot, a new matplotlib windows pops up but doesn't respond (whatever the backend option defined).

I'm running Leopard (10.5) on a ppc machine. What system are you running claumann?
Could be a problem with 10.5 since minrk doesn't have any problem with Lion.

edit: choosing backend = TkAgg or Qt4Agg in the matplotlibrc file solved the problem, ipython qtconsole works fine after that

Chris Laumann

I'm running on Lion with a recent (one year old) intel macbook pro. Basic python world provided by Enthought 7.1-1 (64-bit).

I just updated to the master ipython from github and it still doesn't work with the osx backend. Haven't been able to use any others -- I don't have Qt4 or wxPython installed and using --pylab=tk crashes the kernel after drawing the window for the plot. (with the error message alloc: invalid block: 0x105d3efc0: 47 0)

Chris Laumann

Also, using the html notebook with --pylab=osx backend has the exact same problem of non-responsive plotting windows.

Min RK
Owner

@claumann it makes sense that the behavior is the same between the qtconsole and notebook, as they use the same kernel code (where all the real execution happens).

I typically use matplotlib trunk, which is generally better behaved (much less crashy with the osx backend), but I just installed the 1.0.1 egg from sourceforge, and it still behaves just fine, so I'm baffled. At some point, I will try installing EPD, and see if it behaves any differently. You might try getting the eggs from the scipy superpack, and see if they don't work better.

So: System Python (2.7 on Lion and 2.6 on SL) + git numpy + matplotlib (1.0.1 or trunk) definitely work fine here.

Min RK
Owner

I've looked into this a bit, and it does seem to be unique to EPD. It at least does not affect System Python, and shouldn't affect any official Python.org distros, but it will affect any Python that is built against non-native libtk (could include macports).

I had forgotten that selecting the OSX backend uses the Tk version of the kernel in order to get the zmq polling integrated with the backend eventloop. Using Tk works fine with the system Python because the system Tk is native Cocoa, so the CFRunLoop (the native eventloop) that the osx backend hooks into is that of the Tk app, and events are processed properly. However, EPD's Tk is bizarrely linked against X11 instead of native libraries, so it doesn't advance the CFRunLoop. This explains why the behavior in EPD is the same as if the backend eventloop is not hooked up - it isn't.

I certainly don't blame EPD for shipping their own Tk - the system one is notoriously a mess - but that is the root cause of this issue.

So, essentially we need to figure out a different way to get the CFRunLoop going without using Tk, since Tk can't be assumed to be using the native toolkit.

Any matplotlib and/or Mac folks have clever ideas for how to integrate with the native eventloop when stdin doesn't exist?

Min RK minrk referenced this issue from a commit in minrk/ipython September 20, 2011
Min RK use CFRunLoop directly in `ipython kernel --pylab osx`
via matplotlib.backend_macosx.TimerMac, rather than Tk

Fallback on Tk if matplotlib is < 1.1.0, which introduces the necessary Timer. This means that it still won't work on current EPD, which has X11-linked libtk and matplotlib 1.0.1,
but at least it will display a warning explaining why.

also remove caveat in docs that qtconsole doesn't work with native MacOSX, since it does on normal (non-EPD) installs.

So this will work in more places, but still not in most common failure case (stock EPD) described in #640.
5942e2a
Min RK
Owner

closed by #809. There is still no way to run ipython --pylab osx on matplotlib 1.0.1 with non-native tk, but it works with current dev matplotlib (1.1), which is the best we can do, I think.

Min RK minrk closed this October 14, 2011
Brian E. Granger ellisonbg referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.