iced-nav-scrollable more docs

[?]

Jul 22, 2025, 7:24 PM

FLQWY7L4SH25TQWYM5G7J7ITFRBW6DQQ3M44DDZHVQ6PKUX257BQC

Dependencies

[2] WW36JYLR add iced_nav_scrollable widget crate
[3] GOLHUD6R nav-scrollable: set skip-able sections
[4] SASAN2XC use nav-scrollable

Change contents

replacement in iced_nav_scrollable/src/lib.rs at line 2

[2.171]→[2.171:189](∅→∅)

//! its contents.

[2.171]

[3.1933]

//! its important contents, skipping over sections that are less relevant.
//!
//! The main entry points for this widget that must always be used are:
//!
//! - [`fn init`] creates tasks to determine the size of each of its content.
//! This is completed only once the widget is viewed. If the size cannot be
//! determined, the same tasks keep getting repeated until completion.
//! Therefore you want to make sure to display the widget as soon as you've
//! initialized.
//! - [`fn subs`] must be used to ensure that the sizes of the contents are
//! recalculated on window resize event. Note that if you resize this widget
//! in any other ways you will need to make sure to trigger
//! [`Msg::RefreshOffset`] manually.
//! - [`fn update`] is used to handle message for this instance. The messages
//! from the completion of its tasks must be passed back into it.
//! - [`fn view`] renders the widgets. The number of children given to it must
//! match the number used at initialization.
//!
//! Additionaly, the module exports functions to scroll in various ways. Most
//! relevant are [`fn scroll_up`] and [`fn scroll_down`] which skip through
//! `skip_sections` (i.e. context sections) to navigate between the other more
//! relevant sections.
//!
//! TODO: It sucks that [`fn init`] is tied to the number of contents in order
//! to create tasks to get their sizes, which is then used to determine offsets
//! to their positions. There is a `debug_assert` in [`fn view`] that checks
//! that the number it's been given is the same as the number of elements given
//! to view, but still I found integrating this in inflorescence with usage in
//! multiple different places quite messy and error-prone.
//!
//! Additionally, the iced scrollable has an implicit state for the current
//! offset and it seems to be kept when the widget is replaced with another one
//! at the same layout tree position.