-
-
Notifications
You must be signed in to change notification settings - Fork 251
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
model: Add footer notification for messages. #824
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.
@zee-bit Thanks for giving this issue a go!
I just tried this out and it doesn't seem to work quite as I'd expect, in that it's not triggered in at least this example case:
- narrow to test here > zt1
- compose and send a message to test here > zt2
Note that this shows a message like we want to see, in the webapp.
It may be worth checking the webapp logic to confirm sending from/to all-messages/PMs/mentioned/streams/topics narrows.
You've left quite a lot of debugging statements in there - unless it's relevant to discussion points, it's better to leave those out in the version you push to a PR - you can always keep it in a branch locally and add it back in on a local branch, in a separate commit.
zulipterminal/model.py
Outdated
if not append_to_stream: | ||
self.controller.view.set_footer_text( | ||
'Message sent outside of current narrow', 3) |
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 roughly the response we want to give to the user, but note that since this method handles all incoming new-message events then this will also be triggered by other people sending messages outside of the current narrow.
You could try updating the code here, or have it more directly use the methods which send the message to the server. They should subsequently trigger this method, so it's just doing a check at a different place.
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 have updated the code, to fix the above issue as well as extended it for footer notification outside of streams. I have also amended the tests for model
and now make check
is working fine. I haven't removed debugging statements yet. But I'll do it as soon as the changes are finalized.
I didn't hook up to the methods which send message directly to the server, but I have the code for that in a separate branch locally. I can push that code here if this method does not work for you.
zulipterminal/model.py
Outdated
view = self.controller.view | ||
print("event=>", event, flush=True) | ||
if (len(self.narrow) == 2 | ||
and self.narrow[1][0] == 'topic' | ||
and old_subject != new_subject): | ||
view.set_footer_text("Subject changed", 3) |
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.
Is this a different issue you're working on? If so, best to keep it to a separate commit. Unless it can't be separated, it also isolates which code change was required to fix the issue you're referring to in the commit message.
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.
No, it's for the same issue. This was for the case when a message's subject is edited outside of the current narrow. So the message disappears from the current narrow and is shifted to some other narrow. But, I think the logic behind this is also incorrect. I'll have to think more on this. Any pointers that you would like to give?
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 sort of the same issue, but I think it would be fine to first work on showing a message when sending to a different narrow than the current one, then work on what happens with editing as a follow-up.
I think in both cases the focus is on what the active user does within this ZT session, so it's likely best to hook into the messages to the server, rather than events from it.
d5444ed
to
18982fa
Compare
2b77369
to
13f3f76
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.
@zee-bit This is definitely in the right area of the code now, but note that narrows are in general much more complex than this - including, for example, if I write a PM and I'm in a stream narrow (or vice versa).
Rather than spreading this logic around, I'd suggest making a method which you can test independently and then use in all the locations where we send/update. This could be useful for reasoning about other cases too.
The other aspect you've not considered here is error-handling - we shouldn't show anything if the message is not sent/updated successfully.
8c22b1b
to
52ead7c
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.
@zee-bit This seems to work mostly fine, though there are edge cases in terms of narrows that behave unexpectedly, which you might clarify with tests. I'm also wondering if a longer footer duration may be wise, though this may be simplified if we can use footer message 'themes'?
As per my message in zulip-terminal, #924 may be relevant, though don't feel a need to base this PR on it.
zulipterminal/helper.py
Outdated
@@ -651,6 +651,28 @@ def display_error_if_present(response: Dict[str, Any], controller: Any | |||
controller.view.set_footer_text(response['msg'], 3) | |||
|
|||
|
|||
def notify_if_message_sent_outside_narrow(request: Dict[str, Any], |
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.
request
doesn't really have any meaning in this context.
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.
How about message
?
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's good, though the type will presumably be a Composition 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.
For that, we would need to type-annotate our request
dict(in model
) to appropriate Composition
?
I tried doing this, but it seems like MyPy doesn't allow converting existing dict to TypedDict
(see mypy issue #8890). Is there any other way of doing so?
EDIT: I figured out another way - by annotating the request
dict when creating it, before passing it to the API, and adding total=False
param in StreamComposition
because the stream_id
field should not be added to the request.
This commit generalizes the code for footer notification when a message is sent/edited outside current narrow. This will give the user a pointer as to why the message disappeared from the screen. The code is hooked to the part where message request is sent to the server, hence preventing the extra check for user_id being same as message_sender_id. Tests amended. Fixes zulip#781.
This commit refactors the request dict's type to one of Composition class. Previously, the type of request was Dict[str, Any] which was flexible when it comes type-checking. This change narrows the scope of type-checking, since the Composition class uses TypedDict.
Heads up @zee-bit, 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 will set a footer text notifying the user everytime
he sends or edits a message that is outside the current
narrow. This will give the user a pointer as to why the
message disappeared from the screen.
Fixes #781.