diff options
Diffstat (limited to 'docs/superpowers/plans')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md | 66 | ||||
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md | 72 |
2 files changed, 69 insertions, 69 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 a4aae42..d1daa57 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 @@ -7123,3 +7123,69 @@ real context-menu event and the offscreen platform cannot deliver one. The honest options the entry named were an assertion on the production menu or a hand test; the first is impossible here, so it is the second, recorded in the test so nobody adds an assertion that appears to cover it. + +## 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. + +--- 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 |