Public Access
jaap-janandClaude Opus 5
ed936380b3
Settings, Vaults and Preferences all opened the same full-window settings mode and differed only in which of its seven pages they landed on. SettingsNav, which lists every one of those pages including Vaults and Preferences, is on screen the whole time you are in there — so two of the three rows were deep links into a place the third one opens. They saved one click and cost a menu that read as though it offered three destinations. It was three rows for a reason that had stopped applying. Until v5c, "Settings" and "Preferences" were two doors onto the same bare Preferences screen, and splitting them was the fix for something real; Vaults arrived beside them when VaultsScreen became a settings page too. Folding those two back in is not a return to that state. They are pages now, with a rail of their own, and what a menu at the foot of the nav rail is for is getting into settings at all. Nothing became unreachable — both are one click deeper, from the rail that was always going to be the way to them. ◆ WHAT STAYS, AND WHY IT IS NOT THE SAME ARGUMENT. Logout stays and still lands on the Account page rather than on General, because its confirmation card is drawn inline on that one page while the vault is unlocked; arming it from anywhere else would raise a card nobody could see. The vault switches and New vault above the divider stay too — neither is a page of the settings mode, and the switches have no other home. ◆ THE ROWS ARE REMOVED FROM THE MARKUP, NOT UNWIRED. NavRailTests asserts their absence rather than only asserting that Settings still works, because the failure that guards against is silent: a row left in the markup with its handler deleted is a menu entry that does nothing when pressed, which reads as a broken application rather than a tidied menu. The helper it asserts through excludes the vault switches by their data context and not by their label — a vault is free to be called "Vaults", and a test that a menu entry is absent must not be defeatable by what somebody named a vault. Two facts go, one comes back plus the absence check; the layout suite is 166. Manual check 1.8 walked a reader through all three rows in turn and now walks them through the one, then through SettingsNav's seven — which is where the two went. design-import-gaps.md gains a v5c-5 section rather than an edit to the v5c table: what that table records is what shipped in that pass, and it did. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
76 lines
2.6 KiB
C#
76 lines
2.6 KiB
C#
using Avalonia.Controls;
|
|
using Avalonia.Controls.Primitives;
|
|
using Avalonia.Interactivity;
|
|
using DodoSSH.Client.Shell.ViewModels;
|
|
|
|
namespace DodoSSH.Client.App.Views;
|
|
|
|
/// <summary>The window's destinations, down the left edge — the switcher, the six rail rows and the user chip.</summary>
|
|
internal sealed partial class NavRail : UserControl
|
|
{
|
|
public NavRail() => InitializeComponent();
|
|
|
|
/// <summary>Opens the user popover.</summary>
|
|
/// <remarks>
|
|
/// A handler rather than relying on the click that opening a <c>Flyout</c> answers to on its own: a
|
|
/// named method is a thing a test can call directly, where an implicit open is not.
|
|
/// </remarks>
|
|
private void OnUserChipPressed(object? sender, RoutedEventArgs e)
|
|
{
|
|
if (sender is Control chip)
|
|
{
|
|
FlyoutBase.ShowAttachedFlyout(chip);
|
|
}
|
|
}
|
|
|
|
/// <summary>Hides the popover, whatever handler is about to navigate.</summary>
|
|
private void ClosePopover()
|
|
{
|
|
if (this.FindControl<Button>("UserChip") is { } chip)
|
|
{
|
|
FlyoutBase.GetAttachedFlyout(chip)?.Hide();
|
|
}
|
|
}
|
|
|
|
/// <summary>Leaves for the vaults screen with the new-vault form open, shutting the popover behind it.</summary>
|
|
/// <remarks>
|
|
/// The popover is closed first: the command navigates, and a popup left open would be hanging over a
|
|
/// screen it has nothing to do with. A <c>Flyout</c> does not close on its own when something inside it
|
|
/// is pressed — which is what the vault switches above it want, and not what this wants.
|
|
/// </remarks>
|
|
private void OnPopoverNewVaultPressed(object? sender, RoutedEventArgs e)
|
|
{
|
|
ClosePopover();
|
|
|
|
if (DataContext is MainWindowViewModel shell)
|
|
{
|
|
shell.ShowNewVaultCommand.Execute(null);
|
|
}
|
|
}
|
|
|
|
/// <summary>Opens settings mode on its default landing page — see the remark in the markup.</summary>
|
|
private void OnPopoverSettingsPressed(object? sender, RoutedEventArgs e)
|
|
{
|
|
ClosePopover();
|
|
|
|
if (DataContext is MainWindowViewModel shell)
|
|
{
|
|
shell.EnterSettingsCommand.Execute(SettingsPage.General);
|
|
}
|
|
}
|
|
|
|
/// <summary>
|
|
/// Starts a sign-out, through the Account settings page so the confirmation card has somewhere to be
|
|
/// seen — see <see cref="MainWindowViewModel.SignOutFromPopover"/>.
|
|
/// </summary>
|
|
private void OnPopoverLogoutPressed(object? sender, RoutedEventArgs e)
|
|
{
|
|
ClosePopover();
|
|
|
|
if (DataContext is MainWindowViewModel shell)
|
|
{
|
|
shell.SignOutFromPopoverCommand.Execute(null);
|
|
}
|
|
}
|
|
}
|