diff options
Diffstat (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md | 72 |
1 files changed, 72 insertions, 0 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 0972168..33bba8b 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 @@ -9670,3 +9670,75 @@ The test drives `onSyncFinished()` with the skip code after recording a real pending edit, since `runAutoSync()` correctly declines when there is nothing to carry and a fixture without one would arm nothing for a legitimate reason. Mutation-checked by removing the call. + +## 185. The message-pane bar offers Reply and Forward on a trashed message + +**Observed.** In the Trash view the bar above the message pane reads Reply and +Forward. Neither is a thing to do with a message the user threw away, and the +two actions that are, Restore and Delete permanently, are reachable only from +the Message menu and the context menu. + +**Cause.** `MainWindow::refreshMessageBarActions()` (`mainwindow.cpp:2311`) +picks the bar's message half from exactly one question, whether the displayed +message is a draft: + +- a draft gets `edit_draft` +- everything else gets `reply` and `forward` + +The trash is not a third case, so a trashed message takes the `else` branch. +The knowledge needed is already computed elsewhere: +`refreshTrashActions()` (`mainwindow.cpp:3735`) already decides `inTrash` and +already toggles `delete` and `restore` on it, for the menus. + +**Approach.** Give the bar a third branch that asks the same `inTrash` +question, and fill it with `restore` and `empty_trash`, or with `restore` and a +per-selection permanent delete if the user wants one that is not the whole +trash. The notes ask for both to grey out when nothing is selected, which is +what the existing visibility rules already do for the menu entries; the bar +should read the same actions rather than duplicating the predicate. + +**Constraints.** + +- **One source for the predicate.** `inTrash` is computed in + `refreshTrashActions()`; the bar must read that rather than deriving the + trash-ness a second way, or the two surfaces will disagree the first time a + view changes. +- **"Delete permanently" for a selection does not exist yet.** Item 118 built + `empty_trash` for the whole trash and deliberately gave it the project's one + confirmation. A per-selection permanent delete is a SECOND irreversible + action and inherits that rule, including the confirmation and the absence of + a default shortcut. Decide with the user whether the bar offers the existing + whole-trash action or a new selection-scoped one; they are different items of + work. +- **Item 186 rides with this**, since moving Delete into a bar that still + offers Reply on trashed mail improves nothing. + +**Closed 2026-08-29**, unreleased, the two built together. See the status table in the open file for what shipped. + +## 186. Delete sits on the main toolbar rather than beside Reply and Forward + +**Observed.** The user reads Delete as a message action and expects it in the +message pane's own bar, with Reply and Forward, not on the window's main +toolbar. + +**Cause.** Placement, nothing more: `toolBar->addAction(m_actions.value("delete"))` +at `mainwindow.cpp:2251`, beside `archive`, `mark_all_read` and `undo`. + +**Approach.** Remove it from the main toolbar's list and add it to the +`messageActions` list in `refreshMessageBarActions()`. The action itself, its +scoping and its trash-aware visibility all stay exactly as they are. + +**Constraints.** + +- **Do it with item 185, not before it.** The bar is not trash-aware yet, so + Delete would land next to a Reply button offered on a trashed message. +- **The bar hides over an empty pane** (`messageview.cpp:710`), so Delete + disappears when no message is displayed, where the toolbar kept it visible + and disabled. That is a behaviour change worth confirming rather than + discovering. +- **The no-duplicate-icons test covers the toolbar**, so check + `test_mainwindow`'s icon and menu-reachability assertions still hold after + the move; the action stays in the Message menu either way. + +**Closed 2026-08-29**, unreleased, the two built together. See the status table in the open file for what shipped. + |
