Module ui 

The optional ui section of a mod’s mod.json, the launcher-UI schema the Mods page renders generically: buttons shown for the mod, and the popups those buttons open. See crate::mod_config::ModConfig::ui, which holds this as an Option, a mod without a ui section (e.g. the existing practice-as-race mod) stays fully valid and simply gets no buttons.

Wire shape (per the tournament design contract):

"ui": { "buttons": [ { "id": "create_room", "label": "Create",
                       "action": "tournament.create", "popup": "create_room" } ],
        "popups": { "create_room": { "title": "Create Tournament Room",
                                     "kind": "form", "fields": [ ... ] } } }

Design notes:

• Parse liberally, validate strictly. Every field has a serde default, so a partial ui section (buttons without popups, a popup without fields, …) still parses; structural problems surface as per-mod validation errors from ModUi::validate, collected by crate::mod_config::ModConfig::validate exactly like parameter and rule problems, a broken mod shows up in the launcher’s mod list as broken rather than failing to parse outright.
• Forward compatible. Unknown extra keys are ignored by serde (and reported as non-fatal warnings by crate::mod_config::ModConfig::load_from_path_with_warnings). Unknown kind strings (e.g. a "kind": "datepicker" field written by a newer launcher) round-trip through the UiFieldKind::Unknown / UiPopupKind::Unknown catch-all variants instead of failing to parse, and are then rejected by ModUi::validate with a clear message, same mechanism, at the right layer.
• button.label is displayed verbatim; {placeholder} tokens inside it (e.g. "Join ({room_count})") are filled in live by the launcher (from its current room_list response), never interpolated here.
• button.action strings in the tournament.* namespace are handled by launcher logic; other actions are free-form for future use. This crate stores them opaquely.

Structs

ModUi

A mod’s authored launcher-UI schema: which buttons to show for the mod, and which popups they open. popups is a map keyed by popup id so buttons can reference popups by name, and validation can catch a button pointing at a popup that doesn’t exist (see ModUi::validate).

UiButton

One button rendered for a mod on the Mods page. Clicking it performs action (launcher-handled, e.g. tournament.create), optionally opening the popup named by popup first to collect input.

UiField

One input field inside a UiPopupKind::Form popup.

UiPopup

One popup a UiButton can open: a titled window that is either an input form (UiPopupKind::Form) or a live room list (UiPopupKind::RoomList).

Enums

UiFieldKind

What kind of control a UiField renders. Unknown kind strings round-trip through UiFieldKind::Unknown so they fail validation (with the raw string in the message) instead of failing to parse.

UiPopupKind

What kind of popup a UiPopup is. Unknown kind strings from a newer launcher round-trip through UiPopupKind::Unknown so they fail validation (with the raw string in the message) instead of failing to parse.