Down arrow on GTK3 backends selects toolbar, which eats furthur keypress events

[jtbraun]

• Matplotlib version = 1.5.1
• Python version = 2.7.6
• Platform = Linux, Ubuntu 14.04
• How did you install Matplotlib and Python = python from ubuntu apt, pip install matplotlib
• Example code below

If you use the gtk3-based backends (I had gtk3agg and gtk3cairo installed), and capture keypress events, it works, until you hit the down arrow. The down arrow cause the buttons on the toolbar to be "selected" with a little marquee box, which you can move left/right with the arrow keys. But keys no longer go to the key_press_event handler. Other backends work as expected, all arrow keys are always captured.

import matplotlib

# Broken.  Toolbar appears along the bottom.  Hit the 'down' key, and the selection marquee appears around the
# buttons in the toolbar.  All furthur keypresses go to the toolbar, not the graph window.
# matplotlib.use('gtk3agg')
# matplotlib.use('gtk3cairo')

# OKAY
# matplotlib.use('wxagg')
# matplotlib.use('wx')
# matplotlib.use('tkagg')
# matplotlib.use('qt4agg')

import matplotlib.pyplot as plt
import numpy as np

fig, ax = plt.subplots(1, 1)

x = np.linspace(0, 3*np.pi/2, 1000)
y = np.sin(x)
ax.plot(x, y)

def press(event):
    print "press", event.key

fig.canvas.mpl_connect('key_press_event', press)

plt.show()

[tacaswell]

Did this used to work? My naive guess is that this is a 'feature' of the underlying GTK toolkit which is intercepting the arrow-down and moving the focus to the toolbar. Once this is done then (correctly) the keys are going to that gtk widget instead of the canvas and the mpl python layer no longer sees the events.

attn @fariza

[fariza]

In Gtk3 and Gtk2 for all event handlers we are using the same technique

    def key_press_event(self, widget, event):
        if _debug: print('FigureCanvasGTK.%s' % fn_name())
        key = self._get_key(event)
        if _debug: print("hit", key)
        FigureCanvasBase.key_press_event(self, key, guiEvent=event)
        return False  # finish event propagation?

In Gtk http://www.pygtk.org/docs/pygtk/class-gtkwidget.html#signal-gtkwidget--key-press-event Returns : True to stop other handlers from being invoked for the event. False to propagate the event further

So by returning False we keep the event propagation.

Before going with a PR, is there any case that you can think of that we want the event to keep propagating?

How do we handle that with other backends?

@OceanWolf any thoughts on this?

[jtbraun]

@tacaswell I'm sorry, I don't know if it used to work or not, just that it's different between backends in the current release.

[fariza]

Git blame shows that return False is there since 2005 for Gtk. So this has been the behavior since long time ago (the beginning?).

[WeatherGod]

Well, unless someone can get a seance protocol working for github, I doubt we will ever get an answer to that question, then.

The good news is that since it was like that so long ago, it was well before there was any serious attempt at normalizing behaviors between backends. Heck, it was only about 4 years ago when we finally managed to iron out most of the differences in backends with respect to whether or not plt.show() was repeatable within a single python session.

Unless someone else from back then can remember a good reason why this was set that way, I vote to change it.

[tacaswell]

👍 to changing it as well

On Mon, May 2, 2016 at 11:55 AM Benjamin Root notifications@github.com
wrote:

Well, unless someone can get a seance protocol working for github, I doubt
we will ever get an answer to that question, then.

The good news is that since it was like that so long ago, it was well
before there was any serious attempt at normalizing behaviors between
backends. Heck, it was only about 4 years ago when we finally managed to
iron out most of the differences in backends with respect to whether or not
plt.show() was repeatable within a single python session.

Unless someone else from back then can remember a good reason why this was
set that way, I vote to change it.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6349 (comment)

[OceanWolf]

Heya, I only know of this by the Tab key, but I have done it before by accident pressing the down arrow.

As I understand it you propose changing it so that one cannot shift focus to the toolbar. While this would make MEP27 a bit easier to implement, alarm bells ring for me from an accessibility pov, AFAIK from UI Design, the ability to use the keyboard instead of the mouse for navigating the UI.

However as I have very little knowledge of accessible design, I would like to get some feedback from people who know more about this. Anyone know who we could ask?

[tacaswell]

attn @doraf

I am inclined to say that we should pull this off now and then put the accessible features back in in a systematic way later.

[OceanWolf]

Oh and another place where one might need this, embedded applications. Technically one can work around that with MEP22, creating a Tool that takes the Tab press and routes it to the next item in the tab order, but that feels a little like overkill...

[QuLogic]

One could return True for just the down key, or everything but Tab, though it's unfortunate that FigureCanvasBase's events don't have a "stop" return value, so one doesn't really know if the was actually handled.

[tacaswell]

Closed by #6397