From e6e18849bd5aa49dbdd299982d39a92e7360d0aa Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Sat, 15 Aug 2026 10:44:16 +0200 Subject: docs: open item 94, dropping pinned once the buttons are built-in The user's end state for the query row is built-in filters only, with every saved query living in the menu. At that point SavedQuery::pinned has nothing left to decide. Blocked on 93 and deliberately separate from it: the four buttons have to be lived with first, and if one of them is wrong, pinning is the escape hatch, which has to still exist to be used. Recorded as a user-visible removal rather than a cleanup. pinned shipped in 0.18.0 as a checkbox in SaveQueryDialog and a right-click action, so removing it is a minor bump with an Upgrading note. The stored field is a separate decision from the UI, and leaving it in queries.json unread is both cheaper and reversible. The spec for 93 gains the ordering rule this resolves: filters first in fixed order, the user's pinned queries after them, and nothing configurable, since the mixed row exists only until 94 lands. --- .../plans/2026-08-03-post-0.1.0-usability.md | 45 ++++++++++++++++++++++ .../specs/2026-08-15-builtin-filters-design.md | 16 ++++++++ 2 files changed, 61 insertions(+) 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 9b38d03..884c56b 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 @@ -158,6 +158,7 @@ taking that too literally. | 91 | Double-clicking a thread could open it in its own window | workflow | ? | open, unspecified; the user marked it "(?) UX not sure" | | 92 | Nothing distinguishes a tag written by a rule from one the user applied | information | ? | open, unspecified; the user asked it as a question, and the answer decides whether it is a display item or a format change across two repos | | 93 | The query buttons are whatever the user pinned, not a designed set of filters | workflow | M | open, specified 2026-08-15; see `specs/2026-08-15-builtin-filters-design.md`. Absorbs item 90. Four built-in filters that compose with the account dropdown | +| 94 | `pinned` has nothing left to decide once the buttons are built-in | maintenance | S | open; **blocked on 93**, and deliberately not part of it. A user-visible removal: the row becomes built-ins only and every saved query lives in the menu | Sizes are rough: XS under an hour, S a sitting, M a session. @@ -584,6 +585,50 @@ account deliberately runs nothing, since the button is the verb. **Size: M.** +## 94. `pinned` has nothing left to decide once the buttons are built-in + +**Observed (user, 2026-08-15),** thinking past item 93 rather than from the +notes: + +> after we've migrated [...] we can drop my 4 redundant (by then) saved queries, +> and there won't be a need for pinning anymore. The buttons will be driven by +> the hardcoded queries, the menu will be the home for saved queries. + +**The end state this describes:** the query row is built-in filters ONLY, and +every saved query lives in the menu. No mixing, so nothing has to decide which +saved queries get button real estate, and `SavedQuery::pinned` is dead weight. + +**This also disposes of a problem item 93 would otherwise have to solve.** With +both tiers sharing one row, something must order the four filters against the +user's pinned queries. Under this end state the question does not arise. + +**Blocked on 93, and deliberately not part of it.** The user needs to live with +the four buttons first and confirm they cover what they actually use. If one is +wrong, pinning is the escape hatch, and it has to still be there to be used. +Closing 93 and this together would remove the fallback before it was needed. + +**This is a user-visible removal, not a cleanup.** `pinned` shipped in 0.18.0: +`SaveQueryDialog` offers "Show as a button" (`src/savequerydialog.cpp:104`) and +the right-click menu offers "Move to menu" / "Show as a button" +(`src/mainwindow.cpp:1797`). Anyone who put a saved query on the row loses that +permanently. Semver on the user-visible surface makes it a minor bump with an +`### Upgrading` note. + +**The stored field is a separate decision from the UI.** `pinned` is written to +queries.json (`src/config.cpp:603`) and read back (`:542`). Two options, and the +cheaper one is also the reversible one: + +- **Stop reading it, leave it in the file.** Harmless: an ignored key, preserved + by the unknown-field handling, and a build that reintroduces pinning would + find every user's setting intact. +- **Strip it on the next save.** Cleaner file, and irreversible for anyone who + had it set. + +Prefer leaving it unless the user asks otherwise. No `kQueriesFormatVersion` +bump either way: an ignored optional field is not a breaking change. + +**Size: S.** Removing a field, two UI affordances and their tests. + ## 91. Double-clicking a thread could open it in its own window **Observed (user, notes):** "double clicking a message/thread should open it in diff --git a/docs/superpowers/specs/2026-08-15-builtin-filters-design.md b/docs/superpowers/specs/2026-08-15-builtin-filters-design.md index cd22bab..d44502e 100644 --- a/docs/superpowers/specs/2026-08-15-builtin-filters-design.md +++ b/docs/superpowers/specs/2026-08-15-builtin-filters-design.md @@ -143,6 +143,22 @@ class of complaint item 89 is about. And the account combo is a plain `QComboBox`, so a keyboard user arrowing through it would fire a query per account passed on the way to the one they wanted. +## Ordering, and why it is temporary + +The four filters and the user's remaining pinned queries share one row, so +something has to order them. **Filters first, in the fixed order Unread, Inbox, +Flagged, Sent; the user's pinned queries after them, keeping their own order.** + +Do not build anything configurable for this. The arrangement is transitional: +item 94 removes `pinned` entirely once the user has confirmed the four buttons +cover what they use, after which the row is filters only and there is nothing +left to order. A settings surface for a mixed row would be built and deleted +inside two items. + +`pinned` itself is untouched by this item and stays exactly as it is. The user's +own queries are unpinned as a migration step, which is a change to their data, +not to the mechanism. + ## Constraints - **One rule across all three surfaces.** Buttons, the "more queries" menu and -- cgit v1.2.3