Function set_default_theme 

pub fn set_default_theme(theme: Theme)

Design-system-facing base-theme seed: set_default_theme supplies the starting theme a shell seeds itself with, in place of its own built-in fallback — the seam a design-system plugin’s install() calls. Unlike set_app_theme, this does NOT pin brightness: the shell keeps re-deriving light/dark from the platform’s own appearance against this same base, so a design-system-themed app installed this way still honours system dark mode. See frust_shell_common::theme_default’s module docs for the full precedence order (set_app_theme override → set_default_theme base → the shell’s built-in fallback) and the brightness-following contrast with set_app_theme spelled out in full.

use frust::{Color, Theme, set_default_theme};

// A design-system plugin's install() call, seeding its own base theme as
// the app's starting point without pinning brightness. A real installer
// hands over its whole token set; this one edits a single role off the
// neutral floor to keep the example dependency-free.
let base = Theme::builder(Theme::neutral())
    .map_colors_light(|mut c| {
        c.primary = Color::from_rgb8(0x6B, 0x4E, 0xFF);
        c
    })
    .build();
set_default_theme(base);

Supply the base theme a shell seeds itself with, in place of its built-in fallback. Call before the first frame — typically from a design-system plugin’s install().

Unlike crate::theme_override::set_app_theme, this does NOT pin brightness: the shell’s retained theme object continues to re-derive light/dark from the platform’s appearance against this same base (see the module docs’ Precedence section). A late call (after the first frame) takes effect only if the app later calls clear_app_theme; until then, any active override dominates.

Callable from any thread (see the module docs’ thread contract); the process-wide slot is a plain Mutex, not a UI-thread-only primitive.