Add-Actions & Dialogs

Two more self-registering extension kinds round out the toolbar: add-actions, the "Add …" buttons at the bottom of the left toolbar, and dialogs, the modal surfaces they (and inspectors) open. Both are discovered from packages/app/src/editor/add-actions/ and packages/app/src/editor/dialogs/ respectively — see Extension architecture.

Add-actions

An add-action is the simplest extension kind:

interface AddAction {
  id: string;
  label: string;
  icon?: string;
  run(ctx: ToolContext): void;
}

components/toolbar.tsx renders one button per registered action, below a divider under the tool buttons, in registration order. Clicking a button just calls action.run(ctx).

Add rectangle/ellipse both snap their initial geometry to the 0.1mm grid and cap their default width at min(20mm, panelWidth/2) so a freshly added shape is never larger than the panel it lands on.

Dialogs

A dialog is a registered { id, component } pair rendered by components/dialog-host.tsx, which is mounted once at the root of the Editor and subscribes to a tiny observable open/close store:

interface DialogModule<P = unknown> {
  id: string;
  component: ComponentType<DialogProps<P>>;
}
interface DialogProps<P = unknown> {
  props: P;
  close(): void;
  ctx: ToolContext;
}

Because the store lives outside React (openDialog/closeDialog in registry/dialogs.ts), anything can open a dialog — including a tool's pointer handler, which is not a React component. DialogHost is the single owner of every dialog's modal chrome: it renders the open dialog's component inside a role="dialog" aria-modal="true" backdrop; clicking the backdrop (but not the dialog body itself, which stops propagation) closes it, as does pressing Escape anywhere on the page. It also traps focus inside the dialog while it's open, focuses the first focusable descendant on open (deferred to a dialog component that already moved focus itself, e.g. auto-focusing a search box or a Cancel button), and restores focus to whatever was focused before the dialog opened once it closes. Registered dialog components supply content only — none of this chrome is reimplemented per dialog.

Built-in dialogs

Shortcuts overlay & command palette

The keyboard-shortcuts reference and the command palette are both generated live from the same command registry — the old hand-maintained static shortcuts table is gone. The ?-triggered overlay is now searchable and category-grouped; ⌘/Ctrl+Shift+K opens a fuzzy-searchable command palette that can run any chordless (palette-only) command too, such as Align, New Panel, or Import/Download JSON. See Shortcuts & Command Palette for the full contract.

The sidebar Help panel complements the shortcuts overlay rather than replacing it: the Help panel explains the one tool that is currently active (its per-tool description), while the shortcuts overlay stays the always-available, searchable reference for the app's keyboard shortcuts. Reach for the overlay when you want the shortcut table; glance at the Help footer when you want to know what the tool in your hand does.

Font Explorer dialog

Browses the full 1,942-family Google Fonts catalog with search, category filters (including a Japanese filter derived from font subsets), and starrable favorites — the second tier of the font picker, alongside the text inspector's curated dropdown. See Fonts → The Google Fonts Explorer.

Pattern picker dialog

A responsive grid of pattern thumbnails, one card per entry in PATTERN_GENERATORS (see Patterns → Built-in catalog), each rendered with renderPatternThumb. It opens two ways, both resolving to a single ctx.commit() (one undo entry) before closing:

• With { layerId } (from the pattern inspector) — clicking a card swaps that existing pattern layer's patternType and resets its params to the new pattern's defaults.

• With no props (from the Add pattern… add-action) — clicking a card creates a brand-new pattern layer in the Copper container and selects it.

Each thumbnail is drawn with a useLayoutEffect (not useEffect) so it's sized and painted before the browser's first paint frame — otherwise the <canvas> would flash its default 300×150 box for one frame and the grid would visibly jump.

With the catalog grown to dozens of patterns, the dialog no longer renders every thumbnail up front. A search box (auto-focused on open, same convention as the Font Explorer's search) filters the grid by a case-insensitive substring match against each generator's name (the stable kebab id) or displayName. Below that, cards are rendered page by page: only the first ~24 matching cards mount initially, and a single IntersectionObserver watching a tail sentinel element loads the next page as the user scrolls near the bottom of the grid — the same paged/sentinel pattern the Font Explorer uses for its font cards, rather than per-card visibility tricks (CSS content-visibility would not stop each card's useLayoutEffect canvas draw, so it wouldn't actually defer the work). Typing in the search box resets paging back to the first page of the filtered results.

Trace dialog

The image-to-vector workflow — see Image tracing for the full pipeline it drives. In outline: it decodes the source image layer, downscales and traces it to an SVG (debounced 250ms after any option change), previews that SVG in an <img> (never dangerouslySetInnerHTML, so a hostile trace result can't execute embedded script), and on Apply converts the SVG into PathLayers. The source image is reinserted as a hidden design-time reference in Copper, while each traced path is routed to the material container mapped from its palette paint; the first traced layer is selected. All of that is one ctx.commit().

Trace options exposed in the dialog: a 3-color palette toggle (quantize straight to the fixed panel palette vs. a free 2–8 color count), min shape outline (drops small traced regions below this pixel threshold), and blur radius (pre-blur before tracing, to smooth noisy source rasters).