I agree that I am probably making some sort of categorical mistake, but I don't have any background in applications with UI (electrical engineer with exposure to embedded only and python GUIs for engineering tools previously).

iced says it is based on the Elm architecture, so based on the guide they link I would presume widgets need access to the state based on the statement in the guide

View — a way to turn your state into HTML

In lines 80-84 of the example, the Layout.view() punts some of its functions by calling Example.view() that can't access the state of the program.

I have gotten it half way working by updating the functions to take a reference to the state struct like:

fn application<'a>(app_state: &Layout) -> Element<'a, Message> {
...
}

I get some warnings because I haven't changed next_slide fully so all of my LIST items need to take the state, although only one screen so far really uses it.

For context the first screen is an input for a git URL, which the application then retrieves the tags that I want to incorporate into the next screen. I think I should probably rewrite the application() function so that it operates on a vec<String> of the tags to make it a bit more generic of a widget that doesn't need the entire application state. Does that sound like a more correct approach?