|
|
|
@@ -1,4 +1,4 @@
|
|
|
|
|
# Highlight the chat list filter button while any chat is unread
|
|
|
|
|
# Highlight the chat list filter button, and count support chats as unread
|
|
|
|
|
|
|
|
|
|
## Problem
|
|
|
|
|
|
|
|
|
@@ -6,35 +6,53 @@ The unread filter button in the chat list search bar looks the same whether or n
|
|
|
|
|
|
|
|
|
|
User tags already solve this for themselves: a tag chip carries a `●` badge when its chats have unread (`TagsView` in `ChatListView.kt`, driven by `unreadTags`). The unread filter button had no equivalent.
|
|
|
|
|
|
|
|
|
|
The filter was also missing a whole category of unread. A group where a member is waiting in a support chat has something to read — the chat list row already says so with an accent flag — but the filter did not list it, because the unread test only ever looked at the main conversation. A moderator filtering for unread would silently skip the member waiting on them.
|
|
|
|
|
|
|
|
|
|
## Fix
|
|
|
|
|
|
|
|
|
|
Tint the filter icon with the accent colour while any chat is unread. Same icon, same size — only the colour changes, so it stays visually distinct from the filter's active state (a filled accent pill on Android/desktop, a filled circle glyph at 22pt on iOS).
|
|
|
|
|
Include unread support chats in what the unread filter matches, and tint the filter icon with the accent colour while it matches anything. Same icon, same size — only the colour changes, so it stays visually distinct from the filter's active state (a filled accent pill on Android/desktop, a filled circle glyph at 22pt on iOS).
|
|
|
|
|
|
|
|
|
|
| Filter | Unread chats | Android / desktop | iOS |
|
|
|
|
|
| Filter | Matching chats | Android / desktop | iOS |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| off | none | grey lines | grey lines |
|
|
|
|
|
| off | some | **accent lines** | **accent lines** |
|
|
|
|
|
| on | — | background-coloured lines on accent pill | accent filled circle |
|
|
|
|
|
|
|
|
|
|
## Why `Chat.unreadTag`
|
|
|
|
|
## Why `Chat.hasUnread`
|
|
|
|
|
|
|
|
|
|
The highlight uses `unreadTag` — the same property `ActiveFilter.Unread` matches on in `filtered()` (`ChatListView.kt`) and `filtered(_:)` (`ChatListView.swift`). So the button is highlighted exactly when the filter has something to show, and the unread test cannot drift: it is the same symbol, not two copies of one rule. It also inherits the right mute semantics for free — a muted chat counts only when manually marked unread, and a mentions-only chat only on unread mentions.
|
|
|
|
|
The highlight uses `hasUnread` — the same property `ActiveFilter.Unread` matches on in `filtered()` (`ChatListView.kt`) and `filtered(_:)` (`ChatListView.swift`). So the button is highlighted exactly when the filter has something to show, and the unread test cannot drift: it is the same symbol, not two copies of one rule.
|
|
|
|
|
|
|
|
|
|
`hasUnread` is `unreadTag || supportUnreadCount > 0`. The `unreadTag` half carries the mute semantics — a muted chat counts only when manually marked unread, and a mentions-only chat only on unread mentions. The `supportUnreadCount` half is what the chat list row already flags (`ChatPreviewView`): for a moderator the group's `membersRequireAttention`, otherwise the member's own `supportChat.unread`.
|
|
|
|
|
|
|
|
|
|
Two consequences of taking `supportUnreadCount` whole are deliberate.
|
|
|
|
|
|
|
|
|
|
*Pending members count, and that signal is sticky.* For a moderator `supportUnreadCount` is `membersRequireAttention`, and the core computes `gmRequiresAttention` as `memberPending m || memberAttention > 0 || mentions > 0` (`Types.hs`) — so a member awaiting approval or review counts even with nothing to read. `updateSupportChatItemsRead` (`Store/Messages.hs`) zeroes the support counters but decrements the group's count only when the member stops requiring attention, which a pending member never does; approving or rejecting is what clears it. A moderator with a pending join request therefore sees the button tinted and the group listed under Unread with no unread badge until they act on the request. That is accepted: the member is genuinely waiting on the moderator, and the filter is where they will look for who is waiting. It does disagree with the chat list row, which renders `memberPending` as a grey flag rather than a call to action.
|
|
|
|
|
|
|
|
|
|
*Mute does not suppress the support half.* `unreadTag` gates on `enableNtfs`; `supportUnreadCount` never reads `chatSettings`, and this predicate does not add that gate. Muting a group silences its conversation but not its support chats — a message to or from admins still lights the button. That is intentional: mute is about group chatter, not about the user's own line to the people running the group.
|
|
|
|
|
|
|
|
|
|
Support chats belong in this predicate because `unreadTag` alone cannot see them. `chatStats.unreadCount` is filled by a query scoped to the main conversation (`group_scope_tag IS NULL AND group_scope_group_member_id IS NULL`, `Store/Messages.hs`), so a group whose only unread sits in a member support scope satisfies neither `unreadTag` nor the filter — while the profile picker's badge, whose count comes from `getUsersInfo` (`Store/Profiles.hs`) with no scope filter at all, does include it. Before this the two disagreed: the picker showed a count, the filter button stayed grey and the filter listed nothing, and there was no way to reach the waiting member from the chat list. Matching the picker's notion of unread is the point; sharing one per-chat symbol between the tint and the filter is how it is done without the button being able to lie.
|
|
|
|
|
|
|
|
|
|
Reading `users[].unreadCount` directly was rejected. It is a per-*user* aggregate, so it counts other profiles — including hidden ones, which the toolbar dot deliberately excludes (`!u.user.hidden`) and which must not be signalled on the main screen. It also counts chats the list does not show, reintroducing the `chatDeleted` bug below, and being a count rather than a per-chat predicate it cannot be the symbol the filter matches on, which is the property this whole design rests on.
|
|
|
|
|
|
|
|
|
|
`unreadTag` itself is deliberately left alone: it also drives the user-tag `●` badges, whose counters are maintained incrementally (`updateChatTagReadInPrimaryContext`), and support-unread changes arrive through `updateChatInfo`, which replaces `chatInfo` without running that bookkeeping. Folding support chats into `unreadTag` would desync the tag counts.
|
|
|
|
|
|
|
|
|
|
The predicate also repeats the list-visibility guard `!chatDeleted && !contactCard` that `filteredChats` applies before any filter. Without it the button lies: deleting a contact with "keep conversation" (`ChatDeleteMode.Entity`) routes to `updateContact` → `updateChatInfo`, which replaces `chatInfo` but preserves `chatStats` — so the chat keeps its unread count, becomes `chatDeleted`, and drops out of the list while still satisfying `unreadTag`. The button would stay highlighted with the filter permanently empty, and nothing would clear it because the chat is no longer reachable from the list. This guard is the one rule here that is copied rather than shared — if `filteredChats` ever hides chats on a further condition, this predicate needs the same term.
|
|
|
|
|
|
|
|
|
|
The alternative, `users[].unreadCount`, was rejected: `changeUnreadCounter(user:by:)` increments it unconditionally, so muted chats would light the button while the filter showed nothing.
|
|
|
|
|
|
|
|
|
|
## Reactivity
|
|
|
|
|
|
|
|
|
|
Both platforms already depend on exactly this signal to render the filtered list itself, so no new machinery is needed:
|
|
|
|
|
Both platforms already depend on exactly this signal to render the filtered list itself, so no new machinery is needed for the `unreadTag` half:
|
|
|
|
|
|
|
|
|
|
- Android/desktop — every unread change replaces the chat in the `SnapshotStateList` (`chats[i] = chat.copy(chatStats = …)`), so reading the list recomposes the button.
|
|
|
|
|
- Android/desktop — every unread change replaces the chat in the `SnapshotStateList` (`chats[i] = chat.copy(chatStats = …)`), so reading the list recomposes the button. `updateChatInfo` replaces the element the same way, so the `supportUnreadCount` half recomposes too.
|
|
|
|
|
- iOS — `_updateChat` assigns back into `@Published chats`, and the debounced counter path mutates `@Published users` (a struct array); either fires `ChatModel.objectWillChange`. Note the `UnreadCollector` 1s debounce means the highlight clears a beat after reading a chat, as the filtered list already does.
|
|
|
|
|
|
|
|
|
|
Known gap, iOS only. `supportUnreadCount` reads `chatInfo`, and `updateChatInfo` writes `chats[i].chatInfo = cInfo` — a property write through the `Chat` reference, not an assignment into the array — so it fires `Chat.objectWillChange` but not `ChatModel.objectWillChange`. `ChatListSearchBar` observes the model, not the individual chats, so it does not see that write. For a support-scope item `addChatItem` also skips the `chats[i].chatItems` branch and the unread collector (both are gated on `groupChatScope() == nil`), leaving `throttlePopChat` as the only path back to a model publish — and that enqueues nothing when the group is already at position 0. So when a support message arrives in a group that is already at the top of the list, the tint and the filtered list stay stale until the next unrelated publish (any other chat activity, or re-entering the list, which re-evaluates `filteredChats()`). The chat row's own flag icon is unaffected, since `ChatPreviewView` observes the `Chat`. Android/desktop have no such gap. The one-line fix is to write back into the array in `updateChatInfo` (`let chat = chats[i]; …; chats[i] = chat`, as `_updateChat` does), but that publishes the whole list on every `chatInfo` update and so belongs in its own change, measured.
|
|
|
|
|
|
|
|
|
|
## Scope
|
|
|
|
|
|
|
|
|
|
Not touched:
|
|
|
|
|
- The contacts-list filter button (`NewChatSheet.kt`, `NewChatMenuButton.swift`) — despite the `showUnreadAndFavorites` name it filters favourites, not unread, so an unread highlight there would be wrong.
|
|
|
|
|
- The `ic_filter_list` icon in the "No unread chats" empty state — it only renders while the filter is on and empty, so it correctly stays grey.
|
|
|
|
|
- `Chat.unreadTag`, and with it the user-tag `●` badges and the preset tag counts — see above.
|
|
|
|
|
- The profile picker badge and the toolbar dot. They answer a different question ("another profile has unread", active user excluded) and keep their own count.
|
|
|
|
|
|
|
|
|
|
The change is additive: every pre-existing state renders the identical colour, and exactly one new state is introduced.
|
|
|
|
|
The highlight is additive: every pre-existing colour state is unchanged and exactly one new state is introduced. The filter is not — a group whose only unread is in a support chat now appears in the filtered list where it previously did not, which is the point.
|
|
|
|
|
Narasimha-sc