Struct Theme 

pub struct Theme {
    pub design_system: DesignSystem,
    pub fallback: DesignSystem,
    pub color_scheme: ColorScheme,
    pub adaptive: bool,
    pub fonts: [u32; 9],
    pub palette: Option<&'static Palette>,
}

A design system choice plus how it reacts to the host platform.

Fields

design_system: DesignSystem

fallback: DesignSystem

color_scheme: ColorScheme

adaptive: bool

fonts: [u32; 9]

The font asset each type role resolves to, or zero for the system font.

Per theme and not per node. A node that could name its own font would be a node deciding typography, and the whole point of roles is that it does not: an application changes what Display is made of, and every title changes with it.

Indexed by the role’s wire tag minus one, so the array and the enum cannot drift apart without the compiler saying so.

palette: Option<&'static Palette>

The application’s own colours, laid over whichever design system is chosen.

A reference to something that lives for the whole program, so that a theme stays Copy and can still be built in a const. The same palette goes onto every system an adaptive theme may pick, because a brand colour does not change with the platform. A palette built while the application runs is handed to use_theme, which owns it, so application code never has to give it that lifetime itself.

Implementations

impl Theme

pub const fn unified(design_system: DesignSystem) -> Self

The same design system on every platform.

pub const fn adaptive(fallback: DesignSystem) -> Self

Follows the host platform. The fallback is required, so no platform is left undecided.

pub const fn with_color_scheme(self, color_scheme: ColorScheme) -> Self

pub const fn with_font(self, role: TypeRole, asset: u32) -> Self

Resolves one type role to a registered font, leaving every other role alone.

The asset has to be registered before the theme that names it reaches the Renderer, the same way a picture does. An id that names nothing is reported and the role falls back to the system font, because a screen in the wrong typeface is better than no screen.

pub const fn with_palette(self, palette: &'static Palette) -> Self

Lays the application’s own colours over the design system.

Only colour roles change. Shape, type, spacing, elevation, motion and how each component is drawn stay the design system’s, so the same brand colour reads as that system’s button rather than as a copy of another’s. Both schemes go to the Renderer at once, so a switch between light and dark never asks the Host.

pub const fn font(&self, role: TypeRole) -> Option<u32>

The font this role resolves to, or None for the system font.

Trait Implementations

impl Clone for Theme

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for Theme

impl Debug for Theme

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for Theme

Saying nothing follows the host platform, with Material 3 where the platform has no look of its own. The default used to be unified(Material3), on the theory that a default looking the same everywhere is more predictable. In practice that meant macOS showed a Material screen with no configuration, which is the wrong first impression for a toolkit that claims native desktop UI, and it meant nothing on the default path ever exercised platform adaptation. A default that can be broken without anyone noticing is not predictability. An application that wants one design system everywhere says Theme::unified(..), which is a clearer statement of that intent than silence was.

fn default() -> Self

Returns the “default value” for a type.

impl Eq for Theme

impl PartialEq for Theme

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for Theme