-
-
Notifications
You must be signed in to change notification settings - Fork 278
model/boxes: Add functionality to send typing event to server for PMs. #845
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
Conversation
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.
@prah23 Thanks for looking at this 👍 I'll review this in more detail once you rebase against master to get the tests running, but I've left a few comments.
Also this doesn't seem to send typing stop events before cancelling/sending - eg. if the sender pauses for some time?
b8d5d8c
to
e119f2f
Compare
I haven't sent typing stop events before cancelling/sending because the API seems to do it on its own if it doesn't receive a start event for about 10 seconds. |
e119f2f
to
2e90428
Compare
7056fcf
to
baeeaad
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.
@prah23 This appears to work quite well, including the revised stop events 👍
The windowing on the start/stop events seems to limit the sending of too many messages to the server, which is an important characteristic. For an improved version I would look to avoid generating the many extra threads each time we type. They only sleep and do nothing for such rapid typing, but perhaps we could simplify that in a future refined version.
Could you use the gitlint hook or otherwise wrap your commit text onto multiple lines - gitlint should give helpful feedback (and we can refine the rules we use)
baeeaad
to
c7dd775
Compare
Thank you for the gitlint suggestion. I set the hook up and used it to lint my commit messages. |
@zulipbot add "PR needs review" |
@zulipbot remove "PR needs update" |
c7dd775
to
e8eb246
Compare
e8eb246
to
73b0f51
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.
@prah23 This looks mostly close to being ready 👍 The commit messages look much tidier.
Hopefully most of my points should be straightforward to respond to or address, but let me know :)
I think the remaining concern I have is regarding the number of threads we generate - one on each keypress!
They do mostly sleep and quickly disappear after the sleep period, but I noticed about 78 extra at one point after some rapid typing!
Any thoughts on a slight variation to address this?
7e99d2c
to
dc421ae
Compare
@neiljp I've modified the idleness check method to be called inside the start status function, every time a start status is sent (which is once every 10 seconds, given the user is still typing), and once the idle status function is called, it runs till it finds a 5-second halt. If there is already an idle status thread running, we don't call another one. This way, we'd have very few threads, compared to the previous approach. |
My apologies for re-requesting a review, @zulipbot seems to be down, just wanted to let you know it is updated. I'll wait till you have some time to spare. |
5a058c6
to
db28def
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.
@prah23 Thanks for the update - this shows a good adjustment of the algorithm to avoid the extra threads and still works 👍
I've made some notes inline, but mostly we need to avoid that busy wait, which is the alternative to the multiple threads right now. We have fewer threads, but now one is keeping the CPU busy. Now there's only one extra thread it may be easier to adjust further, however?
Ideally we'd have tests for this; that may be challenging to write, but may make refactoring the code into different forms easier to do, if they're good quality tests!
19b4520
to
3be2bda
Compare
3be2bda
to
a18f80f
Compare
a18f80f
to
de929b5
Compare
Currently, the UserButton only passes itself as the `button` parameter to the private_box_view() when pressed, on the users list. This leads to an inconsistency as the corresponding user_id isn't passed. This commit passes the user_id explicitly, to ensure availability of parameters should there be any need inside the private_box_view in the future.
This commit adds a function to send typing events to the server. The function works asynchronously to avoid a lag between keypress and the corresponding letter's display on the screen. Tests added. The write_box() fixture function in test_boxes.py currently does not have a to_write_box attribute which causes test failures for to_write_box calls inside the keypress tests. This commit sets it to None to support such calls.
This commit captures the user's typing status using urwid's connect_signal(), observing for changes in the msg_write_box. The msg_write_box is connected to a function that sends 'start' events with a limit on how frequently the functions can be called. Idleness is tracked with a method which is initiated when a start event is sent and checks for a possible halt. The corresponding wait periods after the user starts and stops typing are used to restrict calling the function excessively. Fixes zulip#593.
de929b5
to
1cb631f
Compare
This is resolved via the slight adjustment of the key commits in #884, which is now merged. |
Added a function that enables ZT to be sending typing events to the server.
This function is asynchronous to avoid the lag that occurs before the key is displayed on the screen, which is generated by the client making the API call to send the event.
Configured
private_box_view
to use the function to send the event.Fixes #593.