aboutsummaryrefslogtreecommitdiffstats
path: root/docs/superpowers/plans
diff options
context:
space:
mode:
authorDanilo M. <danix@danix.xyz>2026-08-24 11:22:10 +0200
committerDanilo M. <danix@danix.xyz>2026-08-24 11:22:10 +0200
commit55fe1bca09242220e514394acbddb53be796fe40 (patch)
tree217e3bb07cc63298ab32c30fce7ee625a84c03d7 /docs/superpowers/plans
parent2703d4c42710418b0f15a41fa896824e2e1a6170 (diff)
downloadqtmaildir-55fe1bca09242220e514394acbddb53be796fe40.tar.gz
qtmaildir-55fe1bca09242220e514394acbddb53be796fe40.zip
fix(ui): move Compose back, drop the bar below the header, size its icons
Three corrections from looking at the built bar. Compose returns to the main toolbar. The split this was built to, "about a message" against "about the list", does not survive contact: what matters is what the action NEEDS. Reply and Forward are meaningless without a message on display, while Compose needs none and is disabled only when no account can send. So the pane's bar holds exactly the two actions that depend on what it is showing, and Compose sits with the window-wide ones. The bar moves below the subject and details rows, directly above the web view. At the top of the pane it read as window chrome rather than as belonging to the message. The transient notice bars stay above it: they explain the message rather than offer an action on it. Its icons were the style's own default, 16px, which is tiny beside a 32px toolbar. They are now 7/8 of toolbar_icon_size, which is the 28 the user asked for at their 32, derived rather than hardcoded so the relation holds if that key changes. The test asserts the relation as well as the value, since a bare 28 would stop meaning anything the moment the key moved. m_headerLabel gains an object name so the placement test can find the row it must sit below.
Diffstat (limited to 'docs/superpowers/plans')
-rw-r--r--docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md26
-rw-r--r--docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md4
2 files changed, 28 insertions, 2 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
index d1daa57..3c1c8fd 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
@@ -7166,6 +7166,16 @@ that grouping is theirs to make. It shares the container item 141 introduces.
`everyActionIsReachableFromAMenu()` asserts on. This is a second presentation
of the same `QAction`s. Absorbs item 139.
+**Outcome, and the revision the user made on sight.** Built 2026-08-24 with
+Compose, Reply and Forward all on the pane's bar, as the note asked. The user
+then reconsidered: Compose belongs on the main toolbar after all. The reason
+is worth keeping, because it is a better rule than the one this entry was
+written to. The useful split is not "about a message" against "about the
+list", it is what the action NEEDS: Reply and Forward are meaningless without
+a message on display, while Compose needs none and is disabled only when no
+account can send. Compose therefore sits with the window-wide actions, and the
+pane's bar holds exactly the two actions that depend on what it is showing.
+
---
## 141. The message pane has no button bar of its own
@@ -7188,4 +7198,20 @@ from named widget classes, per CLAUDE.md, and this should not become the
exception. Size assumes 140 and 141 are built together; separately they are
each S and the seam between them is wasted work.
+**Outcome.** Message actions left, view controls right, separated by an
+expanding spacer (`QToolBar` has no `addStretch()`), with `toggle_html` the
+first view control. `MessageView::setBarActions()` is the seam, so the pane
+still knows nothing about `MainWindow`'s action map.
+
+**Two things the user corrected on sight, both about placement rather than
+contents.** The bar was first put at the TOP of the pane, above the subject
+and details rows, where it read as window chrome rather than as belonging to
+the message; it now sits directly above the web view, below those rows and
+below the transient notice bars, which explain the message rather than offer
+an action on it. And its icons were the style's own default, which is 16px
+here and tiny beside a 32px toolbar: they are 7/8 of `toolbar_icon_size`,
+derived rather than hardcoded so the relation survives the user changing that
+key. A test asserting the resulting 28 alone would stop meaning anything the
+moment it did, so it asserts the relation as well.
+
---
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index 7f9c606..5a42fb3 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -209,8 +209,8 @@ taking that too literally.
| 137 | A reply to a message that arrived at two accounts can come from the wrong one | defect | S | open, 2026-08-22, found while building item 123 task 12. `ComposeContextBuilder::accountForReply()` takes `messagePaths` PLURAL to disambiguate, and nothing upstream ever gives it more than one path, so the disambiguation is inert |
| 138 | No Drafts filter beside Sent and Trash | workflow | S | open, 2026-08-23, from the notes. Verified: `kQueryGenerators` has no `drafts` entry, though every account already configures a `drafts` folder. Follows the `sent` generator exactly, which composes per-account folders rather than matching a tag |
| 139 | Forward is reachable only from the Message menu | discoverability | XS | **done** 2026-08-24, unreleased, inside 140/141 as that entry said it would be. Forward is on the message pane's own bar with Compose and Reply |
-| 140 | Compose, Reply and Forward belong over the message pane, not on the main toolbar | presentation | M | **done** 2026-08-24, unreleased, with 139 and 141. The three actions LEAVE the main toolbar rather than gaining a second home, which is what makes the toolbar's remaining contents mean one thing (list-wide operations). Same `QAction` objects shown twice over, never copies, so enablement and the menu entries stay single-sourced |
-| 141 | The message pane has no button bar of its own | presentation | M | **done** 2026-08-24, unreleased, with 139 and 140. The design question the entry flagged was settled with the user: message actions left, view controls right, separated by an expanding spacer, with `toggle_html` the first of the latter. `MessageView::setBarActions()` is the seam, so the pane still knows nothing about `MainWindow`'s action map. Two traps: a toolbar has no `addStretch()`, and `noTwoActionsShareAnIcon` took an UNNAMED `findChild<QToolBar*>` which now has two candidates, so it is pinned to `main_toolbar` or it would assert against the wrong bar and pass while the rule went unchecked |
+| 140 | Compose, Reply and Forward belong over the message pane, not on the main toolbar | presentation | M | **done** 2026-08-24, unreleased, with 139 and 141, then REVISED the same day after the user looked at it. Reply and Forward move; **Compose stays on the main toolbar**, because the split that survives contact is what the action NEEDS rather than what it is about, and composing needs no message at all. The moved actions leave the toolbar rather than gaining a second home. Same `QAction` objects shown twice over, never copies, so enablement and the menu entries stay single-sourced |
+| 141 | The message pane has no button bar of its own | presentation | M | **done** 2026-08-24, unreleased, with 139 and 140. The design question the entry flagged was settled with the user: message actions left, view controls right, separated by an expanding spacer, with `toggle_html` the first of the latter. It sits directly above the web view, BELOW the subject and details rows, which was the user's correction after seeing it at the top of the pane read as window chrome. Icons are 7/8 of `toolbar_icon_size` (28 against the user's 32), derived so the relation survives a change to that key. `MessageView::setBarActions()` is the seam, so the pane still knows nothing about `MainWindow`'s action map. Two traps: a toolbar has no `addStretch()`, and `noTwoActionsShareAnIcon` took an UNNAMED `findChild<QToolBar*>` which now has two candidates, so it is pinned to `main_toolbar` or it would assert against the wrong bar and pass while the rule went unchecked |
| 142 | The composer's formatting buttons share a toolbar with Send and Attach | presentation | S | open, 2026-08-23, from the notes. Verified: one `addToolBar` carries Bold through Quote, then Attach, Remove attachment and Send. The user reads the row as a menu bar that is not one. Move the formatting half down to sit directly above the editor, beside the HTML checkbox |
| 143 | The formatting buttons are text, where every editor uses icons | presentation | XS | open, 2026-08-23, from the notes. Follows 142, and cheap once the row moves. `QIcon::fromTheme` per CLAUDE.md's chrome rule, with the text kept as the tooltip |
| 144 | "Also send a formatted copy" is prominent and does not say what it does | presentation | XS | open, 2026-08-23, from the notes. It means "send an HTML part as well as plain text", which the label never says. Secondary to writing the message, so it should read as such |