https://bugs.kde.org/show_bug.cgi?id=524748
--- Comment #1 from [email protected] --- Some implementation detail, since the server-side plumbing for this already exists and appears to be unused. THE ENDPOINT EXISTS AND LIBQUOTIENT ALREADY BINDS IT GET /_matrix/client/v1/rooms/{roomId}/threads is generated in libQuotient as GetThreadRootsJob (Quotient/csapi/threads_list.h), which NeoChat already links. On current master, grep -rn 'GetThreadRoots' src/ returns nothing — the job is available but never called. Today src/messagecontent/models/threadmodel.cpp only models the messages inside a single thread: it fetches with GetRelatingEventsWithRelTypeJob against one m_threadRootId. There is no room-level thread model anywhere in the tree. ORDERING COMES FOR FREE, AND IT IS THE ORDERING BEING ASKED FOR >From the job's documented result: "The thread roots, ordered by the latest_event in each event's aggregated children." So the server already returns roots sorted by most recent activity. That matters because it is precisely the gap: with no thread list, a thread is only reachable where its root event sits in the main timeline, so a thread started yesterday that is still active stays pinned at yesterday's position no matter how recent the last reply. The effective ordering is by first message rather than last. For comparison, Nheko presents a thread list ordered by last activity, and that is the behaviour requested here. USEFUL PARAMETERS ALREADY AVAILABLE ON THE JOB - include=participated — restrict to threads the user has actually taken part in, which would make a sensible default for busy rooms - limit / from — pagination, with the server starting from the most recent event visible to the user THE ASK, CONCRETELY 1. A clear, visible entry point into a room's thread list. SchildiChat on Android is a good reference for the affordance: a button in the room itself, rather than something found by scrolling. 2. That list ordered by last activity — which GetThreadRootsJob returns natively, so no client-side sorting is needed. 3. Per-thread unread indicators, so a thread with new replies is visible without opening each one. Point 2 is the part that bites hardest in daily use: in a room with several long-running threads, the ones with new activity are exactly the ones that stay buried, because their roots are the oldest events. -- You are receiving this mail because: You are watching all bug changes.
