Repository navigation
[Sprint] macosx backend doesn't respond to key_press_events (sometimes) #2120
Description
For some combinations of virtualenvs, distributions, python version, and virtual environments, the macosx backend does not respond to key_press_events.
I can confirm failures with mpl 1.2.1, OSX 10.8.3, anaconda v1.4.6.
From the thread on matplotlib-users, Scott Lasley has failures with:
mpl 1.2.1/1.3.0r2, OSX 10.8, python3.3.2 (framework python.org in virutalenvs)
but
mpl 1.4.x not installed in a virtualenv works.
The following script ought to respond to key_press_events.
import pylab as plt
plt.switch_backend('macosx')
# plt.switch_backend('tkAgg')
def print_event(event):
print event
fig = plt.figure()
fig.canvas.mpl_connect('key_press_event', print_event)
plt.show()
@mdboom edit: Adding "sprint" to the title, since I overheard a lot of work being done on this there.
Activity
dmcdougall commented on Jun 23, 2013
Which keys are you pressing? The events seem to be firing for me.
dmcdougall commented on Jun 28, 2013
For the folks at home, I'm triaging this in person with @mrterry.
We can recreate the issue without virtualenv. It appears that keypress events aren't picked up by the anaconda python stack, but are with the macports. Anaconda's python build is a non-framework build and this doesn't work with OS X's event loop foo. The MacPorts python build is a Framework build and all the relevant events fire properly.
Enthought's Canopy python stack (@katyhuff confirmed this for me) is also a non-Framework build.
The best solution here is to file a bug upstream and make sure our users are getting the best experience on OS X.
katyhuff commented on Jun 28, 2013
correction... it's not clear to me whether it's a framework build. I didn't mean to say it wasn't, just that I didn't see anything obviously framework-y within the Canopy.app directory (which fully contains the installation). This is different from how it seemed epd did things, if I recall correctly (maybe I don't). Canopy does seem to set up a symbolic link from /Library/Frameworks/Python.framework/Versions/Current/bin/python to its canopy.app python ( /Users/username/Library/Enthought/Canopy_64bit/User/bin/python), but the canopy directory isn't organized like EPD used to be... so maybe I'm looking in the wrong places.
dmcdougall commented on Jun 28, 2013
@katyhuff Thanks.
Anaconda definitely isn't a Framework build. @mrterry has sent a message to the anaconda mailing list to follow up.
In any case, #1613 was merged after v1.2 was released so when anaconda updates their matplotlib package, it will fail to build on a mac and they will have the warning message. The necessary motions are set in place so I'm going to close this as 'upstream fix required'.
dmcdougall commented on Jul 1, 2013
I pinged the folks at Enthought and they inform me that Canopy ships with python built as a framework, so we're good there.
mrterry commented on Jul 1, 2013
Good to know. Haven't seen anything on the anaconda side yet.
On Jul 1, 2013 8:37 AM, "Damon McDougall" notifications@github.com wrote:
mdboom commented on Jul 1, 2013
Thinking out loud: should we make the check #1613 a compile-time error message, so folks packaging matplotlib would really really know something went wrong? Maybe that's too obnoxious. Let's wait to hear from Anaconda folks.
dmcdougall commented on Jul 1, 2013
We know it's the framework vs shared library that's causing the issue. The problem is that Anaconda is shipping with v1.2.1, and #1613 was only merged into 1.3, so they don't see the message when they build matplotlib. Also, it's nice to have the flexibility of building python as a shared library and not be completely hosed if someone has no intention of using the os x backend.
We could disable it instead of throwing a build error, but I agree that we should wait to hear back from Continuum first. I'm hoping @mrterry will feed back to us once he hears from them.
@mrterry Please feel free to CC me on the email you sent out to the anaconda list so we're all apprised at the same time.
mrterry commented on Jul 31, 2013
I've having issues with this again. I'm using macports's pythonw (framework build) and building MPL from source. As expected, plain ole python (no "w") does not receive any events.
Turns out Cocoa routes key and mouse events differently. Key events are more complicated The issue appears to be that View (subclasses NSView) is rejecting being FirstResponder for key events and consequently not receiving them. The subsequent PR fixes this issue.
All said, I have about 0.8 days of experience with Cocoa and would really appreciate someone else looking at this.
DanLipsitt commented on Oct 27, 2013
I'm having this problem on Mac OS 10.8.5 with a homebrew build of python 2.7.5.
Here's what happens when I run mrterry's test code, click on the plot, and then type the letter 'a':
$ python Python 2.7.5 (default, Aug 29 2013, 10:40:47) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.27)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pylab as plt >>> plt.switch_backend('macosx') >>> def print_event(event): ... print event >>> fig = plt.figure() >>> fig.canvas.mpl_connect('key_press_event', print_event) 6 >>> plt.show() aaa >>> aaa Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'aaa' is not definedThe plot doesn't seem to take focus when I click it, and the keypresses just go into the console window.
AGG works:
Also, the plot canvas gets a black border around it, suggesting that it has focus.
That's in a virtualenv with matplotlib installed by pip. Outside the virtualenv with a globally pip-installed matplotlib, I get similar behavior except I get a beep with every keypress, and no characters in the console. Also, spacebar activates the home button in the plot window as if it had been clicked.
DanLipsitt commented on Oct 27, 2013
That's matplot 1.3.1 on a framework build of python, by the way.