aboutsummaryrefslogtreecommitdiffstats
path: root/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md')
-rw-r--r--docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md72
1 files changed, 3 insertions, 69 deletions
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 0b1195e..7f9c606 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
@@ -208,9 +208,9 @@ taking that too literally.
| 136 | `undoMovesTheMessageBack` fails when run ALONE, passes in the full suite | defect | ? | open, 2026-08-21, re-measured 2026-08-24 and it is not what the row said. Filed as an intermittent race (1 in 6); it is in fact **deterministic on the selection**: 6 failures in 6 when named on the command line, and 0 failures in the full 258-test run, on a clean tree with the day's work stashed out. All three of its 15s `QTRY` timeouts expire, giving 45s against a 25s whole-suite run, so undo never moves the file rather than losing a race. A test that needs its predecessors is the likely shape (the `init()` lock-table fixture of item 61 is one candidate), which makes it a TEST defect until shown otherwise. Not caused by item 149 |
| 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 | open, 2026-08-23, from the notes. Verified: `forward` is added to `messageMenu` and to no toolbar. Compose and Reply are on the toolbar, so the third member of the set is the only one hidden |
-| 140 | Compose, Reply and Forward belong over the message pane, not on the main toolbar | presentation | M | open, 2026-08-23, from the notes. The user's design: a bar of its own above the message pane carrying the three message actions, leaving the main toolbar for list-wide operations. Absorbs 139, which is the same three buttons in a worse place. See also 141 |
-| 141 | The message pane has no button bar of its own | presentation | M | open, 2026-08-23, from the notes. The container 140 needs, and the home the user names for a `toggle_html` control. Sized as one item with 140 if built together |
+| 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 |
| 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 |
@@ -1375,72 +1375,6 @@ importing the other.
---
-## 139. Forward is reachable only from the Message menu
-
-**Observed.** There is no Forward button anywhere in the interface. The action
-exists and works; it is in the Message menu and nowhere else.
-
-**Cause, verified 2026-08-23.** `mainwindow.cpp:1714` registers the action and
-`1763` adds it to `messageMenu`. The toolbar block at `1975-1994` adds Compose
-and Reply but never Forward, so two thirds of the message-action set are
-visible and the third is not.
-
-**Approach.** One line, if the toolbar is where it belongs. It probably is not:
-item 140 records the user's own view that all three belong over the message
-pane instead, which makes this item the cheap half of that one. Build 140 and
-this closes with it; build this alone only if 140 is deferred.
-
-**Constraints.** The no-duplicate-icons rule covers any action that can reach
-the toolbar, so Forward needs an icon distinct from Reply's rather than a
-variant of it.
-
----
-
-## 140. Compose, Reply and Forward belong over the message pane
-
-**Observed.** The user's note: "'Write new message' and 'reply' live next to
-the other icon only buttons, but they belong in a new bar on top of the message
-pane, together with 'Forward'."
-
-**Cause.** Not a defect. The toolbar grew by accretion and now mixes two
-different scopes: Sync, Archive, Delete, Mark all read and Undo act on the LIST
-or on the selection, while Compose, Reply and Forward are about a message. The
-main toolbar reads as the place for everything, so the distinction is invisible.
-
-**Approach.** A bar above the message pane carrying the three message actions,
-and the main toolbar keeping the list-wide ones. Compose is arguably neither,
-since it needs no message at all; the user grouped it with the other two, and
-that grouping is theirs to make. It shares the container item 141 introduces.
-
-**Constraints.** The actions themselves do not move: they stay in
-`m_actions`, keep their shortcuts, and keep their menu entries, which is what
-`everyActionIsReachableFromAMenu()` asserts on. This is a second presentation
-of the same `QAction`s. Absorbs item 139.
-
----
-
-## 141. The message pane has no button bar of its own
-
-**Observed.** The user asks for "a button bar in the message pane area", and
-names `toggle_html` as a control that would fit it.
-
-**Cause.** Nothing exists to hang such a control on. The pane is a header
-label, the web view, the attachment bar and the tag strip; a per-message
-control has no home, which is why `toggle_html` lives in a menu.
-
-**Approach.** The container item 140 needs. Whether it holds only the three
-message actions, only view controls like `toggle_html`, or both is the design
-question, and it should be settled with the user before building: a bar that
-mixes "act on this message" with "change how I am looking at it" is the same
-confusion item 140 exists to remove, one level down.
-
-**Constraints.** `MessageView` is built inline in its own class rather than
-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.
-
----
-
## 142. The composer's formatting buttons share a toolbar with Send and Attach
**Observed.** The user reads the composer's top row as a menu bar that is not