-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
Migrate mouse_event(s) to use keys_for_command. #539
Conversation
Hello @preetmishra, it seems like you have referenced #533 in your pull request description, but you have not referenced them in your commit message description(s). When you reference an issue in a commit message, it automatically closes the corresponding issue when the commit is merged. Please run An example of a correctly-formatted commit:
Thank you for your contributions to Zulip! |
More on the implementation: I have used
While the for loop would have been the fastest, the implementation would have added 2 more lines and a variable per I had to add |
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.
@preetmishra This makes things clearer and better tested 👍 I've left some feedback inline, though not on every instance, as there is duplication of similar changes between the commits.
Don't worry about having different commits, and improving code as you go, in a commit before the 'new' change.
tests/ui/test_ui_tools.py
Outdated
("mouse press", 4, "up"), | ||
("mouse press", 5, "down"), | ||
("mouse press", 4, next(iter(keys_for_command('GO_UP')))), | ||
("mouse press", 5, next(iter(keys_for_command('GO_DOWN')))), |
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.
Since these calls (or the pop
I recommend elsewhere) are non-deterministic, we should probably take a different testing approach - we want to know that one of the valid up or down keypress keys was used, but that any should work. We could maybe parametrize further, or take another approach.
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 could only validate the first bit (one of the valid up or down keypress keys was used). Could you assist me with how to approach the second bit (but any should work)?
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.
To clarify, I mean by 'any should work', that any key extracted using pop should work, so you should be able to work through those in a test parametrization, or another similar approach.
zulipterminal/ui_tools/boxes.py
Outdated
@@ -652,7 +652,7 @@ def mouse_event(self, size: urwid_Size, event: str, button: int, | |||
col: int, row: int, focus: bool) -> bool: | |||
if event == 'mouse press': | |||
if button == 1: | |||
self.keypress(size, 'enter') | |||
self.keypress(size, next(iter(keys_for_command('ENTER')))) |
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.
You don't have a connected test change for this?
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.
My bad, we didn't have any test for this to change. I have added a test now.
elif is_command_key('GO_UP', key): | ||
key = 'up' | ||
elif is_command_key('GO_DOWN', key): | ||
key = 'down' |
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.
One aspect which makes me wonder if we should approach this differently is that scrolling with the extra keys (vim-like) already works in the stream-view, from the base View
? So it would be simpler if we could avoid adding extra code and tests just for this case.
I can follow why you've added this, but this and the associated test are separate code which are needed before the actual mouse_event is changed - so if we do take this route, I think we should put this in a separate commit, at least for now.
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 had to add GO_UP/DOWN presses for Streams/Topics/UsersView views. They already support navigation through alternative navigation keys (this is defined in View class) but since mouse_event directly calls its keypress method, the addition was necessary to make it work.
I think it is necessary to add these to make this work. I have separated these changes in another commit 381908c with their tests.
ed4df89
to
9f8d739
Compare
9f8d739
to
5b218a9
Compare
@neiljp Thanks. I had to close and reopen the PR in order to restart the build check, it was failing with 'An error occurred while generating the build script.' for I have made my remarks in the respective inline-comments. |
0060d6e
to
86a260a
Compare
@neiljp I restructured the order of commits and made a few changes that eliminate code duplication.
|
86a260a
to
547490b
Compare
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.
@preetmishra I've merged the first commit just now since it was separate and independent 👍
The others seem a little mixed-up, since you introduce some scroll-wheel changes, then replace them in another commit? The 'invalid' mouse events and 'left click' seem clearly separate changes deserving of their own commit(s). Would it be clearer to adjust the mouse_event code to use keys_for_command first? If you can extract the separate changes (extra tests, split-out tests) into independent tests, then the 'flow' of the dependent commits may be clearer?
tests/ui/test_ui_tools.py
Outdated
ids=lambda param: 'scroll_wheel_' + ('up' if param[1] == 4 else 'down') | ||
+ '-key:{}-button:{}'.format(*param) | ||
) | ||
def mouse_press_key_button_pair(request): |
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.
This is specifically for a mouse scrolling action, right? If so, maybe adjust the name accordingly.
Did you keep this out of conftest.py
for a specific reason? (not that all fixtures have to be in there)
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.
Yes, I have renamed the fixture.
I kept this here as it was only being used in ui_tools.py
. Thanks for pointing this out; I have moved this to conftest.py
as we could need it in other files as well.
bb2339e
to
7d39d46
Compare
@neiljp Thanks for the review. I have restructured the commits, to better convey the flow, and incorporated the suggestions that you left in the review.
Hopefully, this will be clearer to review. :) |
@preetmishra I just merged the first and last commits, as these are independent, with a few small changes. I held off on the second as it might be related to the others? In any case, clearer to review these related commits together. |
7d39d46
to
5e5cb4f
Compare
@neiljp I have resolved the conflicts and rebased against |
This introduces parametrize calls in the mouse_event tests for StreamsView and UsersView to reduce code duplication.
The Streams/Topics/UsersView already support navigation using other navigation keys through View but this extension is necessary to get mouse_events ready for using keys_for_command. This also introduces a fixture, mouse_event_navigation_key_expected_key_pair, in conftest, to generate test cases for the keypress tests. Tests added.
* Updated mouse_event functions in MessageView, StreamsView, TopicsView and UsersView to use keys_for_command to ensure that they are future-proof. * Added a fixture, mouse_scroll_key_button_pair, to generate test cases for mouse_event tests. Test amended for MessageView, StreamsView and UsersView and added for TopicsView.
5e5cb4f
to
1860452
Compare
Updated to resolve conflicts. |
Heads up @preetmishra, we just merged some commits that conflict with the changes your made in this pull request! You can review this repository's recent commits to see where the conflicts occur. Please rebase your feature branch against the |
This PR might close tracking issue #533. Are you planning to update/rebase this in near future? |
Hi, @Ezio-Sarthak. Thanks for taking an interest! Feel free to take this further. |
@preetmishra #953 appears to cover the first commit here, and replaces the last commit; I'm not sure about the middle commit? It'd be good to close this out, so if we don't close outright, perhaps @zee-bit may want to take this on given previous work, or @Ezio-Sarthak ? |
@neiljp The middle commit here looks unnecessary after #953. If I understand correctly, it handles 'j/k' keys for scrolling because Perhaps @preetmishra can confirm/validate my above hypothesis before closing this? |
This migrates mouse_event(s) and the associated tests to use
keys_for_command
.I have split the commit into four commits for making it easier to review.
Fixes #533 partially.