Expand description
Menu action dispatch (§ menus). The model (day_spec::MenuItem) is toolkit-neutral and carries
only ids for its actions; the closures live here, keyed by id. A backend fires
Event::MenuAction(id) when a native item is chosen; the event pump routes it to
dispatch_menu_action, which runs the app’s closure. Ids are process-unique and monotonic.
Enums§
- Menu
BarStyle - Arrange an app’s top-level menus into the platform’s standard bar, filling every standard slot the app did not claim with the backend’s stock menu.
Functions§
- app_
menu_ installed - Whether any app menu was installed (an empty model = the backend default menu is up).
- app_
menu_ model - The app menu as last installed (post-injection). The dayscript
menu:step walks it to resolve an item’s dispatch id; backends re-read it on late preferences registration. - dispatch_
menu_ action - Run the closure registered for
id(no-op if none). Called by the event pump onEvent::MenuAction. Runs inside a reactive batch so multiple signal writes coalesce. - has_
app_ menu - Re-forward the retained model through the injection pass: the self-heal for
register_preferencesrunning afterapp_menu(docs/menus.md ordering note). Did the app install a menu model of its own (app_menu)?falsemeans it is running on the backend’s default menu bar, which the backend builds beforeroot()runs, so a backend that puts registration-dependent items there (Settings…, File ▸ New Window) has to rebuild it once the app’s registrations are in. day-toolkit-appkit does exactly that. - rebind_
action - Register an app closure for a menu item and return its dispatch id (nonzero). The
day-piecesmenu builder calls this while lowering a menu tree to theday_spec::MenuItemmodel. Move the closure registered underfromontoto, droppingfrom. - register_
menu_ action - register_
scoped_ menu_ action - Register an app closure whose lifetime is tied to the current scope: the id is dropped
from the dispatch map when that scope is disposed. This is the registrar for closures
owned by a piece build (context menus, nav-row menus, nav
bar_action), which are re-registered on every rebuild; without the cleanup each remount leaks the previous build’s closure (and whatever app state it captured) for the process lifetime. - reset_
menus - Forget every menu action and the last-installed app menu: a re-mount (docs/settings.md “Appearance on Android”). The closures a previous mount registered capture that mount’s reactive graph, which has just been disposed; keeping them would leave the menu bar invoking a dead tree.
- set_
app_ menu - set_
dock_ menu - Install the app’s Dock menu (docs/menus.md “Dock menu”):
itemsgo above the app’s[[shortcuts]]and the system’s own items when the user right-clicks the Dock icon (Cap::DockMenu, macOS). An empty vec leaves only the shortcuts. Replacing the menu drops the previous install’s action closures. - standard_
menu_ bar leadingare the slots before the app’s own menus andtrailingthe ones after; each backend passes its platform’s bar (macOS trails Window and Help; KDE trails Settings and Help; GNOME and Windows trail Help alone).stockreturns the backend’s house version of a slot, orNonewhere that platform has no such menu. Menus the app tagged withday_spec::MenuBarRolereplace the stock one in place, so an app customizes a standard menu by claiming it rather than by rebuilding the whole bar.- standard_
menu_ bar_ for - Assemble the bar for a desktop’s conventions:
standard_menu_barwith that style’s slot order and stock menus.