ScreenManager
NAME
Selkie::ScreenManager - Named multi-screen management
SYNOPSIS
You rarely use ScreenManager directly ā Selkie::App's add-screen
and switch-screen methods forward to its add-screen and switch-to
methods (the App-level name is switch-screen; the ScreenManager-level
name is switch-to). When you do need the underlying object directly
(e.g. to enumerate screen names), reach it via $app.screen-manager:
my $sm = $app.screen-manager;
say $sm.active-screen; # 'main'
say $sm.screen-names; # ('login', 'main', 'settings')
# Route a keybind based on the active screen
$app.on-key('ctrl+n', -> $ {
given $app.screen-manager.active-screen {
when 'tasks' { create-task }
when 'notes' { create-note }
}
});
DESCRIPTION
A tiny registry mapping screen names to root containers, with one marked
as active at a time. Selkie::App uses it to park inactive screens
off-screen while preserving their state.
Switching screens is fast ā the inactive roots remain fully built, just repositioned off-screen. Their widgets keep their state (text input buffers, scroll positions, cursor positions) until the screen is reactivated.
EXAMPLES
Checking before registering
unless $app.screen-manager.has-screen('settings') {
$app.add-screen('settings', build-settings-screen());
}
Cleanup
Remove a screen you no longer need (e.g. after logout). Attempting to remove the active screen throws:
$app.switch-screen('login');
$app.screen-manager.remove-screen('main');
remove-screen unsubscribes the screen's entire widget tree from the
store before destroying it, so a build-screen / remove-screen cycle
leaves the store's subscription count exactly where it started. Check
it with $app.store.subscription-count either side of the cycle if
you are chasing a leak; a rising count means something in your tree
holds children somewhere neither children nor content reaches.
SEE ALSO
Selkie::App ā wraps
ScreenManagerwith higher-level conveniences