fix(view): stop clipping the date, and make the accent bar visible

Both found by rendering real cards to an image and looking at them, not by any
assertion. The suite was green through both.

The date lost the leading digit of its year on every UNREAD card. The layout
reserves the date's width from the font it is handed, which is the view's
regular font, while the delegate paints with the bold one the model supplies for
unread: 154px reserved against 170px needed. CardLayout now measures the date
bold whatever font it is given, so the reserved width cannot be narrower than
what is drawn. A few pixels are wasted on a read card, which is the cheap side of
the trade.

The accent bar was painted correctly and was invisible. Blending the account
colour 0.35 toward the palette's Base, as the plan specified, is a fraction OF
THE ACCOUNT COLOUR, so on a dark theme it produced (0.18, 0.22, 0.26) against a
Base of (0.169, 0.169, 0.169): the background. The blend is dropped entirely.
An account colour is already chosen to be a chip's fill carrying legible text,
so it is muted to begin with, and nothing is drawn on the bar that needs that
contrast. The spine keeps a blend, at 0.55, because it runs the full height of
every reply in an expansion and is a different problem from a 3px edge marker.

The bar is still faint at 3px on a dark theme, since the account colours are
chosen as chip fills. Whether kAccentWidth needs raising cannot be settled
without the user's own accounts, screen and theme; that is Task 10's open
question and it is left open.

1 files changed, 15 insertions, 11 deletions

diff --git a/src/carddelegate.h b/src/carddelegate.h
index 317c78a..7012eaa 100644
--- a/src/carddelegate.h
+++ b/src/carddelegate.h
@@ -52,17 +52,21 @@ public:
     static QRect expanderRectFor(const QStyleOptionViewItem &option,
                                  const QModelIndex &index);
 
-    /// An account's colour as a thin LINE rather than as a chip's fill.
+    /// The colour the accent bar is painted in: the account's own, undiluted.
     ///
-    /// Never use the raw account colour for the accent bar or the spine. That
-    /// colour is chosen to be a background with legible text drawn on top
-    /// (TagColors::textColourOn picks black or white against it). The same
-    /// colour as a few pixels of line on the pane's own background is a
-    /// different problem: it has to be followable down a long expansion
-    /// WITHOUT competing with the senders beside it, which is the constraint
-    /// threadLineColour() states and meets by blending 0.35 toward the
-    /// palette's text. This blends the account colour toward the palette's
-    /// Base by the same weight, keeping the hue that identifies the account
-    /// and dropping the saturation that would shout.
+    /// Blending it toward the palette's Base was tried first, at the 0.35
+    /// weight threadLineColour() uses, and produced an INVISIBLE bar on a dark
+    /// theme: against a Base of (0.169, 0.169, 0.169) it landed at (0.18, 0.22,
+    /// 0.26), which is the background. The weight is a fraction OF THE ACCOUNT
+    /// COLOUR, so a low one keeps the background rather than the hue.
+    ///
+    /// An account colour is already chosen to be a chip's fill with legible
+    /// text on top, so it is muted to begin with; three pixels of a muted
+    /// colour is nothing. Nothing is drawn on this bar, so it needs none of the
+    /// contrast that choice was made for. The SPINE is where the muting belongs
+    /// and is blended in paint(): it runs the full height of every reply in an
+    /// expansion and has to be followable without competing with the senders.
+    ///
+    /// Falls back to threadLineColour() for a thread with no account tag.
     static QColor accentLineColour(const QColor &accountColour);
 };