-
Notifications
You must be signed in to change notification settings - Fork 96
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
Ui tester api updates4 - Implement locating textbox in RangeEditor and performing KeySequence #1171
Conversation
…wrapper (and a couple simple fixes)
… more detailed documentation for it
LargeRangeSliderEditor, | ||
LogRangeSliderEditor, | ||
RangeTextEditor, | ||
SimpleSliderEditor, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eventually we will want to add SimpleSpinEditor, but this can be done in a later PR.
For later reference: The SimpleSpinEditor class in Qt has a control that is a QtGui.QSpinBox object, which subclasses QtGui.AbstractSpinBox which has a lineEdit() method which returns the QLineEdit for the spin box (likely we would just need to resolve to this and then the other handlers should work). For wx however, the SimpleSpinEditor has a control of a wx.SpinCtrl, which is supposedly combines a wx.SpinCtrl and wx.TextCtrl in one. However, it doesn't seem to subclass wx.TextCtrl and doesn't appear to support the same methods, so our handlers for KeyClick, KeySequence, etc. may not work correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Some comments to do with documentation for developers and error feedbacks for the users. Mostly LGTM!
I think we can normalize the use of \b
in KeySequence
for Qt and Wx.
This is worth noting: With this PR, the test coverage for traitsui.wx.range_editor
went from 25% to 60%, and the test coverage for traitsui.qt.range_editor
went from 40% to 65%. 🎉
# There is a problem with KeySequence on wx. trying to include the key | ||
# '\b' does not succesfully type a backspace. Instead EmulateKeyPress | ||
# seems to literally type "\x08" which leads to errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If both the wx and qt widgets respond to the backsapce keys correctly, that is, the behaviour is the same, then the test code should be toolkit agnostic. That's the purpose of the tester API and we should aim to support that.
I'd propose we translate \b
to the backspace key for wx TextCtrl such that the test code can use \b
in KeySequence
. In other words, in key_sequence_text_ctrl
, we do this:
if char == "\b":
char = "Backspace"
Then we can run check_set_with_text
for both qt and wx. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense so me, but would we then need to hard code all other escape characters? for example '\b', '\t', '\n', etc. That may be just what we need to do and that is perfectly fine. I had just left the tests separate for now. so that the issue was known and we could try to address it. It seems very likely to me that this may be the only solution, but I didn't know if there may would be a way to get the escape characters to work directly without explicitly checking and swapping them for the pyface key names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are only a few of these characters so I think it is not a big deal: We can maintain this as a separate mapping. Alternatively we can forbid the use of \b
in KeySequence and force test code to use KeyClick("Backspace"), but we should choose one route, not both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KeyClick("Backspace")
with an optional argument for the # of backspaces sounds a lot better than manually doing \b
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, then we would have to check for \b
in the Qt implementation to disallow it. Otherwise test code trying to use \b
would not be toolkit agnostic. In either case, these escape characters need to be handled one way or another.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, I think either way is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KeyClick("Backspace")
with an optional argument for the # of backspaces sounds a lot better than manually doing\b
.
It makes sense to me to support both. My understanding is just that we want the code to be toolkit agnostic. I added kits suggestion for now so that '\b' works on both wx and qt. Maybe in a later pr we can add to the KeyClick functions to take an optional argument to repeat the specified character n times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I looked a bit more into the "\b"
business, looks like wx is actually happy with it.
@@ -43,7 +43,7 @@ def key_click(widget, key, delay=0): | |||
else: | |||
wx.MilliSleep(delay) | |||
key_event = wx.KeyEvent(wx.wxEVT_CHAR) | |||
key_event.SetUnicodeKey(KEY) | |||
key_event.SetKeyCode(KEY) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this results in another test to fail:
======================================================================
FAIL: test_key_click (traitsui.testing.tester.wx.tests.test_helpers.TestInteractions)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/kchoi/Work/ETS/traitsui-clone/traitsui/testing/tester/wx/tests/test_helpers.py", line 96, in test_key_click
self.assertEqual(textbox.Value, "A")
AssertionError: 'a' != 'A'
- a
+ A
I think the test failure makes sense because to type "A", one needs to have the cap on or have used the Shift key. Apparently Qt disagrees and would happily insert a capitalized "A"
in that case. So the two disagree and we should normalize it. 😂
That's orthogonal though we should open a separate issue to solve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once #1176 is merged and if we re-run the CI for this PR we should see this test failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I modify the test to pass and comment on the discrepancy? I can open a separate issue about it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized that the tests with wx and key clicks are actually failing on Windows.... this is getting orthogonal. Let's revert this change to SetKeyCode
and modify the tests for RangeEditor here so that it does not rely on backspaces, then open a separate issue to fix the discrepancies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Sigh, we did this again... It is hard to see new test failures with wx CI job being allowed to fail. Here are the new errors on Windows:
|
:/ At least it seems to be the effectively same issue #1177. |
Implements the sixth bullet on issue #1149 (Implement locating the textbox in RangeEditor and then perform KeySequence event on it.)