pub struct ChipSpec {
pub glyph: String,
pub fallback: String,
pub color: String,
pub enabled: bool,
pub in_palette_bar: bool,
pub badge_key: Option<String>,
pub glyph_svg: Option<PathBuf>,
pub glyph_codepoint: Option<String>,
}Expand description
Visual + interaction settings for the sibling’s chip. Display
strings (label, description) live at IntegrationSpec top
level, not here — the chip is about rendering, not identity.
Fields§
§glyph: String§fallback: String§color: String§enabled: bool§in_palette_bar: bool§badge_key: Option<String>§glyph_svg: Option<PathBuf>Path (relative to the sibling repo root, or absolute) to an
SVG file the sibling owns and wants baked into mnml’s
runtime symbols font. On install_integration the file
is copied to ~/.config/mnml/glyphs/<integration-id>.svg;
mnml discovers it on next startup (or on the
integrations.refresh palette command), assigns a stable
codepoint, and — on integrations.bake_sibling_glyphs —
bakes the SVG into ~/Library/Fonts/MnmlSymbols.ttf so the
chip renders the branded glyph.
Leaving both this and glyph_codepoint unset means “use
whatever glyph says” — the pre-SDK behaviour where
siblings pick a Nerd Font codepoint by hand.
glyph_codepoint: Option<String>Optional explicit codepoint the sibling wants (uppercase
hex, no U+ prefix — e.g. "F1C05"). When set, mnml uses
this codepoint verbatim for the sibling’s SVG bake instead
of auto-assigning one from the sibling PUA range
(U+F1C00–U+F1CFF). Useful for migration cases where a
sibling wants to keep the codepoint mnml core baked before
this SDK feature landed. Trusted — no range validation
beyond “parses as u32”; the manifest author is expected to
stay inside mnml’s PUA layout documented in
src/icon_catalog.rs.