pub struct NavProps {
pub documents: Option<DocumentTabsConfig>,
pub title: String,
pub presentation: NavPresentation,
pub adaptive: bool,
pub sidebar_toggle: bool,
pub search: Option<SearchProps>,
pub list_width: Option<f64>,
pub list_visible: bool,
}Expand description
Navigation host (docs/navigation.md).
Fields§
§documents: Option<DocumentTabsConfig>Document-tab chrome, independent of navigation destinations.
title: String§presentation: NavPresentationThe presentation to draw now; re-presented in place by NavPatch::Presentation.
adaptive: boolThe app left the presentation automatic (NavStyle::Automatic, or a Sidebar
nav host with no .presentation(…) pin), so it is free to follow the window.
Only a toolkit answering Cap::NavRepresent = Emulated needs this: its own adaptive
container owns the morph, and it must know whether the app asked for one at all before
building it. With two presentations that bit could be inferred from a lowered Split;
with four it cannot, so it is carried explicitly rather than encoded.
Native re-presenters ignore it (they are told each presentation as it is resolved),
and so do toolkits that cannot re-present.
Draw the platform’s own show/hide-sidebar affordance on this host’s chrome
(docs/toolbars.md). true for every nav(Sidebar) unless the app opted out:
the toolkit owns both the button and the behavior
(NSToolbarToggleSidebarItemIdentifier, the split view’s collapse on GTK,
NavigationView.IsPaneOpen on XAML), so an app that once declared the item by hand
now declares nothing. Hosts with no sidebar ignore it.
search: Option<SearchProps>Search over this navigation surface (Nav::searchable, docs/search.md).
None = the surface is not searchable and no field is rendered anywhere.
list_width: Option<f64>Some(width) = this host has a content-list pane (Pane::List) at this preferred
width in points, between the sidebar and the detail (docs/navigation.md). Read at
realize, because a backend that builds a different container for a three-pane host
(UIKit’s triple-column style is init-only) needs to know before it builds. None on
every host without one, including all of them on backends answering
crate::Cap::NavContentList Unsupported: the pieces layer composes there and
the prop is never set.
list_visible: boolWhether that pane is showing for the destination the host opens on
(Nav::content_list_for). Read at realize, like list_width, and for a
related reason: a backend whose pane is a real split item can only honor a
collapsed state reliably by setting it before the item joins the split. Told
afterwards (by NavPatch::ListVisible, on a window that has not been displayed
yet), AppKit reports the item collapsed and then lays it back out from its holding
priorities, and the app opens with a list beside a page that does not own one.
true on every host whose first destination has a list, and on hosts with no pane
at all, where it means nothing.