Trait ThemeTokens 

pub trait ThemeTokens: 'static {
    // Provided methods
    fn primary(&self) -> Color { ... }
    fn on_primary(&self) -> Color { ... }
    fn radius(&self) -> f32 { ... }
    fn radius_sm(&self) -> f32 { ... }
    fn radius_md(&self) -> f32 { ... }
    fn radius_lg(&self) -> f32 { ... }
    fn spacing(&self) -> f32 { ... }
    fn font_size(&self) -> f32 { ... }
    fn icon_size(&self) -> f32 { ... }
    fn spacing_sm(&self) -> f32 { ... }
    fn spacing_md(&self) -> f32 { ... }
    fn spacing_lg(&self) -> f32 { ... }
    fn spacing_xl(&self) -> f32 { ... }
    fn muted(&self) -> Color { ... }
    fn scrollbar(&self) -> Color { ... }
    fn ink(&self) -> Color { ... }
    fn surface(&self) -> Color { ... }
    fn surface_alt(&self) -> Color { ... }
    fn border(&self) -> Color { ... }
    fn success(&self) -> Color { ... }
    fn warning(&self) -> Color { ... }
    fn error(&self) -> Color { ... }
    fn info(&self) -> Color { ... }
    fn highlight_low(&self) -> Color { ... }
    fn highlight_med(&self) -> Color { ... }
    fn highlight_high(&self) -> Color { ... }
}

Opt-in semantic-token contract the built-in component catalogue reads through, so a component can resolve a token without knowing the concrete theme type.

Every method carries a default, which makes impl ThemeTokens for MyTheme {} valid and each token an independent opt-in: a theme answers the questions it cares about and lets the catalogue keep its own answer for the rest. This trait is deliberately not where a theme’s vocabulary lives — that belongs to the theme’s own type, reachable in full through use_theme. What is here is only the subset a component written without knowledge of that type has to be able to ask for.

The metric tokens are bases, not a size scale. A catalogue component derives its own proportions from font_size rather than asking for a named role, because naming the roles would decide for every application which roles may exist. One number scales the type; the component keeps its own ratios.

Provided Methods

fn primary(&self) -> Color

fn on_primary(&self) -> Color

fn radius(&self) -> f32

Base corner radius in px. A component rounds by this, or by a step of the scale below where its shape asks for one (a pill is not a card).

fn radius_sm(&self) -> f32

The steps either side of radius, so a theme owns how round everything is instead of each component keeping its own literal.

This is the axis an application actually restyles, and a scale of three steps derived from one base is what a design system needs to be reachable from outside. A component that hardcodes BorderRadius::all(8.0) is not themeable at all — the caller can change the base radius and watch nothing move — and the fix is not a prop per component but a token they all read.

A theme that wants a flat scale returns the same number from all three; one that wants a rounder language moves the base and the steps follow.

fn radius_md(&self) -> f32

fn radius_lg(&self) -> f32

fn spacing(&self) -> f32

Base gap between adjacent things in px, and the unit a component derives its own padding from.

fn font_size(&self) -> f32

Base body text size in px. Every catalogue component scales its own text off this, so changing it scales the whole type ramp.

fn icon_size(&self) -> f32

Default size of a standalone icon in px.

fn spacing_sm(&self) -> f32

The steps either side of spacing, so a theme owns how much air everything has instead of each component keeping its own literal.

Note the base sits in the middle here, where the radius base is the largest step: “how round is the biggest thing” and “what is the default gap” are different questions, and a scale that pretended otherwise would make every component either cramped or airy the moment a theme moved one number.

A theme that wants a flat rhythm returns the same number from all four; one that wants a roomier language moves the base and the steps follow.

fn spacing_md(&self) -> f32

fn spacing_lg(&self) -> f32

fn spacing_xl(&self) -> f32

fn muted(&self) -> Color

fn scrollbar(&self) -> Color

fn ink(&self) -> Color

Primary text ink for component labels/titles/values. A theme should override it, but the default follows the active light/dark mode rather than assuming light: a theme that overrides surface and forgets ink used to paint near-black text on its own dark panel.

fn surface(&self) -> Color

The background a floating panel sits on — a menu, a dropdown, a dialog. Opaque by default, because the thing it covers must not read through it, and mode-following for the same reason as ink.

fn surface_alt(&self) -> Color

A quiet, low-contrast surface tone for chip/tag backgrounds. Defaults to a faint neutral wash.

fn border(&self) -> Color

Hairline border/divider tone. Defaults to a faint neutral.

fn success(&self) -> Color

Semantic status colours. Defaults are conventional hues; a theme should override to match its palette.

fn warning(&self) -> Color

fn error(&self) -> Color

fn info(&self) -> Color

fn highlight_low(&self) -> Color

Three progressively stronger highlight/elevation tints for hover, selection, and pressed states. Defaults to faint neutral washes a theme can override with palette-specific tones.

fn highlight_med(&self) -> Color

fn highlight_high(&self) -> Color

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors