GNOME Bugzilla – Bug 712217
Message counter should not increase on currently selected channel/direct chat
Last modified: 2021-06-10 11:05:52 UTC
When I am talking to someone (/query) the sidebar continues to show indication of missed messages with the person I am in the conversation with.
Not sure this is what we/jakub wants. The next patch hide the counter label in the current active channel. So messages that we didn't saw yet, still counts as a unread messages (i.e. when the scroll is above the misread messages) and the counter label will show up again when the channel becomes unfocused.
Created attachment 260272 [details] [review] roomList: Hide counter on active channel Hide the counter label on the current active channel since it is supossed the user is following the current conversation.
Created attachment 260300 [details] [review] roomList: Hide counter on active channel Hide the counter label on the current active channel since it is supossed the user is following the current conversation.
(In reply to comment #3) > Hide the counter label on the current active channel > since it is supossed the user is following the current > conversation. I don't think this assumption is necessarily true - when I come back after a while (lunch etc.), I might scroll up to read up on missed conversations. If I'm mentioned while doing so, I need an indication of it or else I'm gonna miss it. So I'd rather make sure that messages are correctly acknowledged (and possibly use a small timeout for the counter, so that it doesn't flash briefly for messages that we acknowledge almost instantly).
(In reply to comment #4) > (In reply to comment #3) > > Hide the counter label on the current active channel > > since it is supossed the user is following the current > > conversation. > > I don't think this assumption is necessarily true - when I come back after a > while (lunch etc.), I might scroll up to read up on missed conversations. If > I'm mentioned while doing so, I need an indication of it or else I'm gonna miss > it. > > So I'd rather make sure that messages are correctly acknowledged (and possibly Not sure what "messages are correctly acknowledged" means. Let's talk about this in IRC when available =) > use a small timeout for the counter, so that it doesn't flash briefly for > messages that we acknowledge almost instantly). Sounds reasonable for the flash issue.
Just throwing some ideas out there: maybe scrolling back to the position of such messages and waiting long enough (a timer, to ensure the user was not just "scrolling past" instead of reading) and/or typing and sending a message could clear the notification counter.
Created attachment 263055 [details] [review] chatView: Fix condition for scrolling pending messages on screen Currently the first pending message is scrolled on screen for inactive rooms only, to avoid interfering with backlog reading. This is a rather poor solution though, as auto-scrolling is the desired behavior when not reading backlog. To fix, change the condition to test for the current scroll position instead, as we already do for non-highlighted messages. Meh, hidden in plain sight. There might be other bugs here of course, but this definitively should take care of a couple of cases ...
Review of attachment 263055 [details] [review]: works fine here. Is the flashing issue another one different then?
(In reply to comment #8) > Is the flashing issue another one different then? Yes. Both the room list and the chat log monitor the channel for new messages (TpTextChannel::message-received). In response, the room list updates the counter, and the chat log adds the message to the text view. Adding the message to the text view triggers the GtkAdjustment::changed signal, in response to that we check whether we should auto-scroll to the bottom - if we do that, the highlighted messages becomes visible and is marked as read (non-highlighted messages may be marked as read directly after receiving them, but those are not relevant for the counter anyway). If the message were marked as read directly after receiving, there would be a quick flash if the room list handler is run before the chat log one. However as the chat log will return control to the main loop first, the flashing is pretty much guaranteed to happen (unless there are very serious redraw issues). This still needs fixing, but as mentioned in comment #4, just using a small timeout for updating the counter should do the trick. Also nekohayo's suggestion of marking pending messages as read when *sending* a message is worth considering IMHO - at least to me it makes sense :-)
Comment on attachment 263055 [details] [review] chatView: Fix condition for scrolling pending messages on screen Attachment 263055 [details] pushed as 4b551a5 - chatView: Fix condition for scrolling pending messages on screen
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Polari, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/polari/-/issues/ Thank you for your understanding and your help.