yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Settings rows: one line with inline icon actions #231

New Issue
Closed
opened 2026-08-25 08:29:33 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-25 08:29:33 +01:00
Owner
Copy Link
Copy Source

Settings rows are hard to scan. Each root and each policy spends two lines: the
path or name on the left, chips pushed to the right edge, then EDIT and
DELETE on a line of their own below. With four roots and four policies the
rows run together and it takes effort to see where one ends and the next begins.

Bring each row onto one line: identity on the left, chips after it, edit and
delete as inline icon actions on the right. Adjacent rows need to read as
separate — whatever does that, a rule or spacing, rather than relying on the
reader to parse two-line groups.

The delete action keeps its arm-then-confirm behaviour (armedDelete); this is
about where it sits and what it looks like, not what it does. Do not introduce a
second confirmation idiom.

Icon-only follows the ruling in #230: the glyph carries the action and the
aria-label carries the meaning, including which row it acts on — delete on
its own is not enough when eight rows offer the same glyph.

Goes through the impeccable skill. Drive a real browser with agent-browser,
never google-chrome --headless. Check it at a narrow width too: a one-line row
with chips and actions is the layout most likely to break when it cannot fit,
and it must degrade rather than overflow the page.

Scope: web/src/settings.ts and the settings rules in web/src/style.css. The
signal chain section that moved here in #173 is not part of this.

Settings rows are hard to scan. Each root and each policy spends two lines: the path or name on the left, chips pushed to the right edge, then `EDIT` and `DELETE` on a line of their own below. With four roots and four policies the rows run together and it takes effort to see where one ends and the next begins. Bring each row onto one line: identity on the left, chips after it, edit and delete as inline icon actions on the right. Adjacent rows need to read as separate — whatever does that, a rule or spacing, rather than relying on the reader to parse two-line groups. The delete action keeps its arm-then-confirm behaviour (`armedDelete`); this is about where it sits and what it looks like, not what it does. Do not introduce a second confirmation idiom. Icon-only follows the ruling in #230: the glyph carries the action and the `aria-label` carries the meaning, including which row it acts on — `delete` on its own is not enough when eight rows offer the same glyph. Goes through the `impeccable` skill. Drive a real browser with `agent-browser`, never `google-chrome --headless`. Check it at a narrow width too: a one-line row with chips and actions is the layout most likely to break when it cannot fit, and it must degrade rather than overflow the page. Scope: `web/src/settings.ts` and the settings rules in `web/src/style.css`. The signal chain section that moved here in #173 is not part of this.
naps62-yolo added this to the Feedback pass 2 milestone 2026-08-25 08:29:33 +01:00
naps62-yolo added the type/bugarea/webdifficulty/moderate labels 2026-08-25 08:29:33 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/web difficulty/moderate type/bug
Milestone
No items
No Milestone Feedback pass 2
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#231
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?