8000 Qt4 keys by mrterry · Pull Request #2273 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Qt4 keys #2273

New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 20 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
add tests for Qt Key handling
  • Loading branch information
mrterry committed Sep 19, 2013
commit b454f327722be5a23c6bc18ff3c918f82e713ccc
99 changes: 98 additions & 1 deletion lib/matplotlib/tests/test_backend_qt4.py
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,17 @@
from matplotlib._pylab_helpers import Gcf
import copy

import mock
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a new mpl dependency? I've no problem using mock (it is the go to for things like this), just wanted to clarify whether we need to update docs etc. ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah -- seeing this, I can see the advantage of this, and I wouldn't want to reinvent the mock wheel. (It it might prove to be useful elsewhere).

We should update the docs. Since we now have automatic dependency resolution, we should update the setupext.py configuration for Tests as well. And maybe, for good measure, in case all that fails, mark these tests as "skip" or "knownfail" if mock is not installed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mock is convenient, but not necessary for my tests. i can get the same effect by attaching several lambda self: return_value to an Object() The total line count will be essentially the same.

give me a yea or nay on mock, and I'll add the needed things to setupext.py


try:
import matplotlib.backends.qt4_compat
from matplotlib.backends.qt4_compat import QtCore
from matplotlib.backends.backend_qt import MODIFIER_KEYS
HAS_QT = True

ShiftModifier = QtCore.Qt.ShiftModifier
ControlModifier, ControlKey = MODIFIER_KEYS['ctrl']
AltModifier, AltKey = MODIFIER_KEYS['alt']
SuperModifier, SuperKey = MODIFIER_KEYS['super']
except ImportError:
HAS_QT = False

Expand All @@ -34,3 +42,92 @@ def test_fig_close():
# assert that we have removed the reference to the FigureManager
# that got added by plt.figure()
assert(init_figs == Gcf.figs)


def assert_correct_key(qt_key, qt_mods, qt_text, answer):
plt.switch_backend('Qt4Agg')
qt_canvas = plt.figure().canvas

event = mock.Mock()
event.isAutoRepeat.return_value = False
event.key.return_value = qt_key
event.modifiers.return_value = qt_mods
event.text.return_value = qt_text

def receive(event):
assert event.key == answer

qt_canvas.mpl_connect('key_press_event', receive)
qt_canvas.keyPressEvent(event)


@cleanup
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the cleanup decorator is only for when we are plotting

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assert_correct_key makes a figure and sends it events. Does that qualify as "plotting"? All the same, I'll document this better to clear up an future issues.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I missed that. Yes, that does count as "plotting".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be easier to go with a test class that has a setup and teardown so we don't have to do cleanup for each test function here? Don't know if it would make a difference or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this way is more robust. A test class would presumably have a single, shared figure that all the callback test use. I don't fully trust key_press_events cough_macos_cough to actually get fired. In the event that one doesn't fire, the test will eventually time out. I don't know what cascade gets launched if I'm using a class based test with a shared figure and one of the tests times out.

That and I like functions : )

@knownfailureif(not HAS_QT)
def test_shift():
assert_correct_key(QtCore.Qt.Key_A,
ShiftModifier,
u'A',
u'A')


@cleanup
@knownfailureif(not HAS_QT)
def test_noshift():
assert_correct_key(QtCore.Qt.Key_A,
QtCore.Qt.NoModifier,
u'a',
u'a')


@cleanup
@knownfailureif(not HAS_QT)
def test_control():
assert_correct_key(QtCore.Qt.Key_A,
ControlModifier,
u'',
u'ctrl+a')


@cleanup
@knownfailureif(not HAS_QT)
def test_unicode():
assert_correct_key(QtCore.Qt.Key_Aacute,
ShiftModifier,
unichr(193),
unichr(193))


@cleanup
@knownfailureif(not HAS_QT)
def test_unicode_noshift():
assert_correct_key(QtCore.Qt.Key_Aacute,
QtCore.Qt.NoModifier,
unichr(193),
unichr(225))


@cleanup
@knownfailureif(not HAS_QT)
def test_alt_control():
assert_correct_key(QtCore.Qt.Key_Control,
AltModifier,
u'',
u'alt+control')


@cleanup
@knownfailureif(not HAS_QT)
def test_control_alt():
assert_correct_key(QtCore.Qt.Key_Alt,
ControlModifier,
u'',
u'ctrl+alt')


@cleanup
@knownfailureif(not HAS_QT)
def test_modifier_order():
assert_correct_key(QtCore.Qt.Key_Aacute,
(ControlModifier & AltModifier & SuperModifier),
u'',
u'ctrl+alt+super+' + unichr(225))
0