Skip to content

Navius WPF

The Navius component catalog, carried onto native WPF. Lookless custom controls with real UIA automation peers and real ControlTemplates, no WebView anywhere.

Navius WPF carries the Navius component catalog onto native WPF: lookless custom controls, Control subclasses with no fixed visual tree, styled entirely through ControlTemplate, each backed by a real AutomationPeer wired to Windows UI Automation. There is no browser control and no WebView anywhere in the stack.

Parity, as this project defines it, is not a DOM emulation running inside WPF. It means the WPF port matches the web catalog’s surface, API semantics, keyboard matrix, and accessibility outcomes, rebuilt on WPF’s own mechanics: ControlTemplate, AutomationPeer, dependency properties, routed events. In practice that split is roughly 85% rebuilt against native WPF idioms and 15% direct code transfer, the clearest case being SpringSolver, whose spring physics is pure C# and crosses over unchanged.

One consequence of rebuilding rather than emulating: the web library’s one honest deviation from Radix dissolves entirely on WPF. NaviusSlot exists on the web only because Blazor has no way to merge props onto a caller-supplied child element (an asChild approximation, already an acknowledged deviation per the web port’s own ADR-0003). WPF composes through ControlTemplate, ContentPresenter, and named template parts as its native model, so there is no child-element “props object” to merge onto in the first place. The WPF port retires NaviusSlot outright rather than porting an approximation of an approximation (see this port’s ADR-0003).

  • Navius.Wpf.Primitives, the lookless brain: behavior, keyboard handling, and UIA peers, no visual opinion.
  • Navius.Wpf.Ui, the styled layer: ControlTemplates over the same token system as the web catalog.
  • Navius.Wpf.Charts and Navius.Wpf.Motion round out the suite: chart rendering and a spring-based motion engine, the latter sharing its solver with the web port.

Building Release, net10.0-windows, from the four src projects at the pinned M6 commit (e5e1a55) produces: Navius.Wpf.Primitives.dll at 573 KB, Navius.Wpf.Ui.dll at 95 KB, Navius.Wpf.Motion.dll at 37 KB, and Navius.Wpf.Charts.dll at 20 KB, about 710 KB combined across the four assemblies. For scale, typical open-source WPF component suites pack to several MB, and commercial suites to tens of MB; these four assemblies land well under either bar, though this measures raw assembly size, not a packed NuGet artifact with themes, resources, and multi-target builds included.

Every page under /components is a manifest for one lookless WPF port of a Navius primitive: frontmatter (the control type, namespace, base type, UIA control type, web equivalent, and how it’s verified), then Overview, Usage, one API table per part (Properties, Methods, Commands, Events), Keyboard interactions, the UIA mechanism it drives, and its deltas from the web contract. See SCHEMA.md in the source repo for the exact shape every manifest follows, and llms.txt for a flat link index built for retrieval; every page is served both rendered and as raw markdown so a coding agent can read it directly.

1,281 tests are green at the pinned commit: 1,212 unit, 38 motion, 23 charts, 2 vendoring, and 6 UIA end-to-end tests driven against real windows. Beyond the suite, every family carries a recorded M6 adversarial audit in its manifest. These are counts, not conformance claims.