diff options
Diffstat (limited to 'src/notmuchworker.h')
| -rw-r--r-- | src/notmuchworker.h | 37 |
1 files changed, 37 insertions, 0 deletions
diff --git a/src/notmuchworker.h b/src/notmuchworker.h index 2efddaa..8171f3c 100644 --- a/src/notmuchworker.h +++ b/src/notmuchworker.h @@ -18,6 +18,7 @@ #pragma once +#include <QHash> #include <QMap> #include <QObject> #include <QStringList> @@ -212,6 +213,22 @@ public slots: /// whatever the current view happens to be showing. void resolveQueryMessages(const QString &query, const QString &requestTag); + /// Subjects for the list behind the unsynced-changes count (item 119). + /// + /// Takes the snapshot's ids in order, each flagged as a thread id or a + /// message id, and answers POSITIONALLY: one subject per input, plus a + /// message count for a thread id and -1 for a message id. Positional + /// because the caller has already decided what its rows are and in what + /// order; a set-based answer would make it match them back up by id, and + /// one id can legitimately appear on several rows. + /// + /// An id the index no longer holds yields an EMPTY subject rather than + /// being dropped. The dialog still shows that row: the count the user + /// clicked has to equal the list they are shown, and silently dropping a + /// row would break that for the one case where it matters most. + void resolvePendingSubjects(const QStringList &ids, + const QList<bool> &areThreads); + private: /// The shared walk behind resolveMessages() and resolveThreadMessages(): /// runs `query` and emits threadMessagesResolved() with each match's id, @@ -281,6 +298,16 @@ public slots: /// root does not change while the application runs. void requestMailRoot(); + /// Counts messages per sender address over `query`. + /// + /// Index-served, so it is cheap: measured 2026-08-26 on the developer's + /// database, 1322 distinct senders in 12 ms over 5105 messages. It does + /// NOT touch m_generation, which is the QUERY generation: bumping it would + /// discard a thread load in flight and blank the message pane because the + /// user synced. Item 169, following the same rule requestMessageCounts + /// already follows. + void countSenders(const QString &query); + signals: void threadsReady(const QVector<ThreadSummary> &threads, quint64 generation); void queryFinished(int totalThreads, quint64 generation); @@ -329,6 +356,12 @@ signals: const QStringList &paths, const QStringList &tags, const QString &requestTag); + /// One subject per requested id, in the SAME ORDER, and one count beside + /// it: the thread's message total, or -1 for a message id. An empty + /// subject means the index no longer holds that id. + void pendingSubjectsResolved(const QStringList &subjects, + const QList<int> &messageCounts); + void allTagsReady(const QStringList &tags, quint64 generation); /// One entry per requested query, in the order they were asked for. A query @@ -356,6 +389,10 @@ signals: /// treat as "cannot compose a path yet" rather than as the root being "". void mailRootReady(const QString &mailRoot); + /// One sender per entry, lower-cased, with how many messages over `query` + /// came from it. The candidate list for the business-senders file. + void senderCountsReady(const QHash<QString, int> &counts); + void errorOccurred(const QString &message); private: |