Skip to content
UrushiDocumentation

Presentation model

Urushi uses the same presentation concepts for plain output, prompts, and full-screen TUIs. The concepts below match the sections in this sidebar: start with the term that describes what you need to control.

Build and render your first shared View →

These are cooperating parts of one model, not competing ways to build an interface. Choose the card that names the result you want; each page begins with a runnable example and continues into the relevant settings.

A View is the common value at the center of the model. A component keeps semantic data separate from its presentation, and a theme picks that presentation and the styles for semantic roles. Both produce Views without choosing a terminal backend.

Styles determine how the View’s cells look. Layout determines how Views occupy space and relate to one another. Text width determines how their content is measured in terminal cells. Canvas is a specialized View for content whose position or overlap must be expressed in those cells explicitly.

The completed View can then be resolved for an ordinary CLI write, a prompt, Urushi’s full-screen runtime, or a caller-owned Ratatui buffer. Those surfaces have different event and output lifecycles, but they consume the same presentation model.

Terminal graphics extend that model at its anchor boundary: an image reserves space as a View, then Kitty or Sixel pixels overlay the resolved region. Graphics are therefore not another layout primitive, and Canvas remains cell-space drawing rather than a pixel rasterizer.