aboutsummaryrefslogtreecommitdiffstats
path: root/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
diff options
context:
space:
mode:
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.md72
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.
+