Skip to content

feat: hierarchical command palette#185

Draft
seankmartin wants to merge 14 commits into
masterfrom
feat/command-palette
Draft

feat: hierarchical command palette#185
seankmartin wants to merge 14 commits into
masterfrom
feat/command-palette

Conversation

@seankmartin

Copy link
Copy Markdown
image

seankmartin and others added 14 commits June 7, 2026 18:28
pattern now follows default viewer_setup binding
also fixes the lifetime and binding locations to be more consistent with the default
viewer setup and the input event bindings to help panel
Also removes doc level palette key listener, this was designed for when inside a number
element for e.g. but not worth
also explicitly labels the command type as opposed to infer from optional properties
Extract the catalog — CommandCatalog, CommandCatalogContext,
collectActionBindings, the CommandPaletteEntry types, and the tool/label
helpers — from command_palette.ts into a new command_catalog.ts with no DOM
or CSS dependencies. command_palette.ts keeps the Overlay-based CommandPalette
UI and bindCommandPalette, importing the catalog and the stylesheet.

Previously, importing CommandCatalog for its enumeration transitively pulled
in command_palette.css and the Overlay class even when no palette was
rendered. Splitting the modules lets the catalog be consumed (and unit-tested)
without a DOM, and reused independently of the palette UI.

- command_catalog.spec.ts (renamed from command_palette.spec.ts) now imports
  from command_catalog.js, so the catalog tests no longer depend on the
  palette module.
- default_viewer_setup.ts imports CommandCatalog from command_catalog.js and
  bindCommandPalette from command_palette.js.

No behavioural change.
refactor: split CommandCatalog into a DOM-free command_catalog module
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants