Merge branch 'card-list': the thread pane as a list of cards

Replaces the five-column grid with a single column of three-line cards. Item 53
recorded that the columns, not the cues drawn inside them, were what made the
list read as a table of records; item 20 had already shipped finished, tested
and green and been rejected on sight for exactly that reason.

A card is sender and date, subject with the flag, attachment and reply-count
marks, and tags, at one uniform height. Replies indent under a continuous spine
and show only the tags their thread does not carry. The account colour runs down
the card's left edge, replacing the chip that used to eat a third of every
subject line, with matching swatches in the account dropdown. Sorting newest or
oldest first is new and remembered.

Closes items 20, 51, 53 and 60.

The four defects that mattered were all found by rendering cards to an image and
looking at them, with the suite green through every one: a date clipped on unread
cards because bold is wider than the font the layout measured, an accent bar
painted in a colour identical to the background, an expander pill in a palette
role a theme had made equal to Base, and three separate faults from trusting
notmuch's reply depth to mean structure when it only means how notmuch happened
to thread the mail.

1 files changed, 40 insertions, 1 deletions

diff --git a/src/notmuchworker.h b/src/notmuchworker.h
index 7d6a587..1d8c8c0 100644
--- a/src/notmuchworker.h
+++ b/src/notmuchworker.h
@@ -44,10 +44,24 @@ public:
     /// Threads emitted per threadsReady() signal.
     static constexpr int kBatchSize = 200;
 
+    /// The sort orders offered to the user.
+    ///
+    /// Two, not four. notmuch also has NOTMUCH_SORT_MESSAGE_ID and
+    /// NOTMUCH_SORT_UNSORTED, and neither is an order a human wants. Sorting
+    /// by sender or subject is deliberately absent: notmuch cannot do it, so
+    /// the model would have to sort after results arrive, which fights the
+    /// batching that makes a 10k-thread query paint immediately.
+    enum SortOrder {
+        NewestFirst,
+        OldestFirst,
+    };
+    Q_ENUM(SortOrder)
+
 public slots:
     /// Runs a query. generation lets the UI discard results from a superseded
     /// query without the worker needing to know about cancellation.
-    void runQuery(const QString &query, quint64 generation);
+    void runQuery(const QString &query, quint64 generation,
+                  SortOrder sort = NewestFirst);
 
     /// Loads the messages of one thread, oldest first. matchQuery is the
     /// user's current query; messages matching it render expanded, the rest
@@ -55,6 +69,28 @@ public slots:
     void loadThread(const QString &threadId, const QString &matchQuery,
                     quint64 generation);
 
+    /// Loads a thread as a reply TREE, for the message rows in the list.
+    ///
+    /// Separate from loadThread rather than replacing it, for a reason that is
+    /// not stylistic: loadThread walks notmuch_query_search_messages, and a
+    /// message obtained that way returns NULL from
+    /// notmuch_message_get_replies (notmuch.h:1617-1628), so that walk cannot
+    /// produce reply depth at all. The tree has to come from
+    /// notmuch_thread_get_toplevel_messages instead. The message pane still
+    /// wants the flat list; only the list wants the tree.
+    ///
+    /// matchQuery is accepted for signature symmetry with loadThread and is
+    /// deliberately unused: see the comment on the walk in the .cpp.
+    void loadThreadTree(const QString &threadId, const QString &matchQuery,
+                        quint64 generation);
+
+    /// Loads ONE message, for a message row selected in the list.
+    ///
+    /// Emits messageLoaded with an empty vector when the id is unknown, which
+    /// is an ordinary race after a reindex rather than an error worth
+    /// reporting.
+    void loadMessage(const QString &messageId, quint64 generation);
+
     /// Applies tag changes. Opens the database read-write, applies, and closes
     /// immediately: notmuch's write lock is exclusive process-wide, so holding
     /// it would block the user's cron `notmuch new`.
@@ -100,6 +136,9 @@ signals:
     void threadsReady(const QVector<ThreadSummary> &threads, quint64 generation);
     void queryFinished(int totalThreads, quint64 generation);
     void threadLoaded(const QVector<MessageRef> &messages, quint64 generation);
+    void threadTreeLoaded(const QVector<MessageNode> &nodes,
+                          quint64 generation);
+    void messageLoaded(const QVector<MessageRef> &messages, quint64 generation);
     void tagsApplied(const TagChange &change);
     void allTagsReady(const QStringList &tags, quint64 generation);