René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Searchable/filterable settings navigation","articleBody":"## Problem or Motivation\n\nThe settings navigator (`SettingsNavigator`) renders a flat, ever-growing list\nof settings sections (General, Appearance, App, AI, Input, Shortcuts, Memory,\nMCP Servers, Hooks, Extensions, Permissions, Labels, Messaging, Server,\nWorkspace, Preferences — 16 sections today). There is no way to filter it.\n\nComparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all ship a\n**search box at the top of their settings** so users can jump to a setting by\ntyping part of its name instead of scanning the whole list. OpenWork's session\nlist, sources list, model picker, and tools list already have search affordances\n— settings is the conspicuous exception.\n\n## Proposed Solution\n\nAdd a search box at the top of `SettingsNavigator` that filters the section list\nby **title and description** (case-insensitive, substring). It mirrors the\nexisting `SessionSearchHeader` styling (search icon, clear button, focus ring)\nfor visual consistency, shows a \"No results found\" empty state when nothing\nmatches, and supports `Esc` to clear.\n\nThis is a **frontend-only** change:\n- `SettingsNavigator` already has all section metadata (`SETTINGS_ITEMS`,\n  resolved labels/descriptions) in the renderer. Filtering is pure client-side\n  React state — no backend, no qwen-code change.\n- Reuses existing i18n keys (`common.search`, `common.noResultsFound`), so no\n  new locale strings are introduced.\n\n## Alternatives Considered\n\n- Command-palette navigation already exists, but it is a separate global\n  surface; users in the settings panel expect to filter the list they are\n  looking at, the way every comparable app does.\n\n## Additional Context\n\nFeasibility: **frontend-only / doable.** Verified against `apps/electron` and\n`packages/ui` — the navigator is a pure renderer component and the data it\nneeds is already in memory.\n\n### Acceptance criteria (CDP e2e assertion)\n\nA new `e2e/assertions/settings-search.assert.ts` drives the real built app over\nCDP and asserts the full path:\n\n1. Open **Settings** from the sidebar; the search box renders and the section\n   list shows more than one row.\n2. Typing the first section's title narrows the list to exactly the predicted\n   matches, every visible row actually contains the query, and the list shrinks.\n3. A no-match query (`zzqqxxnomatchzzqqxx`) shows the empty state and hides every\n   row.\n4. Clearing the query restores the full list.\n\nPart of the autonomous desktop-feature loop (`loop-bot`).","author":{"url":"https://github.com/DragonnZhang","@type":"Person","name":"DragonnZhang"},"datePublished":"2026-06-30T13:08:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/39/openwork/issues/39"}