Measure the vault column instead of arguing about it

Nothing in this repository loaded a .axaml, so the one class of defect this
window has actually shipped — a control arranged past the edge of its container,
where it cannot be clicked — was the one class nothing could catch. The setup
screens rendered sliced once, with their buttons unreachable. The vault column is
the next candidate: 340 pixels wide, two lists and two editors, and the only
thing keeping it from clipping its own Save button at the window's 520-pixel
minimum is a state rule that one editor may be open at a time.

That rule was added on the strength of an argument. This adds an
Avalonia.Headless project that lays real XAML out at a real size and reports
what a user could not reach, and the argument is now a number: with both editors
open the column overflows, so the rule is load-bearing rather than defensive.
BothEditorsAtOnce_DoNotFit_WhichIsWhyTheRuleExists is the test, and it says what
to do if it ever starts passing — the column has room, so delete the rule, not
the test.

Two findings arrived by measuring rather than by reasoning, and the first one
changed the design.

MainWindow cannot be shown headlessly at all. Showing it attaches the terminal's
NativeWebView, whose Win32 adapter initialises WebView2 on attach, and WebView2
refuses a non-STA thread — which is exactly why Program.Main carries [STAThread]
and is written down in that comment. A HeadlessUnitTestSession owns its
dispatcher thread and offers no apartment choice, so the whole window is out of
reach at any size. That is pinned as a test asserting RPC_E_CHANGED_MODE by
HResult rather than by message, so a future Avalonia that makes the adapter lazy
will fail it and the harness can be widened.

So the column had to become its own control to be measurable, which is the
extraction the type-selector rework wanted anyway. Keyboard release moved with
it: MainWindow used to call Focus() on HostList by name, and now asks
VaultColumn.KeyboardTarget. The window decides that the keyboard should leave the
terminal and the column decides where it lands — which is the seam the rework
needs, because once the column shows one list at a time, "which list owns the
keyboard" is a question only the column can answer.

The second finding is the way this kind of test lies quietly. The hint class
lived in MainWindow.Styles and carries TextWrapping. A Window's styles reach its
whole tree, so nothing about the application depended on where it lived — but a
control laid out on its own loses them, and every hint paragraph would have
measured as a single line. The harness would have passed while measuring heights
that were all too small. The three shared classes now live in App.axaml, which
changes no rendering and makes the measurement honest.

The detector is calibrated in both directions, because a clipping detector that
never fires reads as a guarantee: a deliberately clipped Save button is caught by
name, and a list longer than its viewport is exempt. Scrolling is how a list is
supposed to handle more rows than fit, and without that exemption the host list
would fail the moment it had content. It also mis-fired once and the rule is
narrower for it — an empty ListBox is zero pixels tall and correct, so "arranged
with no size" now applies only to controls the theme gives a height to.

Skia rather than the headless drawing stub, deliberately. The stub's font manager
invents glyph metrics, and text height is an input to every stacked panel in this
column, so measuring against it would produce numbers that are self-consistent
and unrelated to the application.

A separate test project rather than more tests in DodoSSH.Client.App.Tests.
Avalonia's application, dispatcher and platform are process-global singletons
initialised once, and that project's identity is the shell's state machine
without Avalonia — the whole reason sign-in is a delegate. The fakes needed to
reach a real unlocked vault are shared from DodoSSH.Client.Session.Tests by
source link: a project reference would make one test project a library of
another, and a copy would be a third implementation of the same decision table
drifting from the other two.

855 tests green, 10 of them new. Zero warnings, dotnet format clean.

Not done, and this is groundwork rather than the item itself: the type selector.
The column still holds both lists at once, so a third item type would still
recreate the defect the one-editor rule works around. What is different is that
the rework can now be checked instead of eyeballed — including the claim it is
being made for, that one editor at a time stops being a runtime rule and becomes
a fact about what is in the visual tree.

What this harness will never catch is the terminal's native child window
compositing over Avalonia content. That is a Win32 property of a real window, no
headless surface reproduces it, and it is the reason the WebView is collapsed
rather than covered.
This commit is contained in:
2026-07-30 11:34:09 +02:00
parent 211eba0666
commit c5dec2d68e
14 changed files with 1639 additions and 198 deletions
+11 -197
View File
@@ -1,6 +1,7 @@
<Window xmlns="https://github.com/avaloniaui"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:vm="using:DodoSSH.Client.App.ViewModels"
xmlns:views="using:DodoSSH.Client.App.Views"
x:Class="DodoSSH.Client.App.Views.MainWindow"
x:DataType="vm:MainWindowViewModel"
Title="DodoSSH"
@@ -10,25 +11,7 @@
MinHeight="520"
Background="#10131a">
<Window.Styles>
<Style Selector="TextBlock.hint">
<Setter Property="Foreground" Value="#7b8394" />
<Setter Property="TextWrapping" Value="Wrap" />
</Style>
<Style Selector="TextBlock.heading">
<Setter Property="Foreground" Value="#e6e9f0" />
<Setter Property="FontSize" Value="18" />
<Setter Property="FontWeight" Value="SemiBold" />
</Style>
<Style Selector="Border.card">
<Setter Property="Background" Value="#171b24" />
<Setter Property="CornerRadius" Value="8" />
<Setter Property="Padding" Value="24" />
<Setter Property="MaxWidth" Value="520" />
<Setter Property="VerticalAlignment" Value="Center" />
<Setter Property="HorizontalAlignment" Value="Center" />
</Style>
</Window.Styles>
<!-- The shared classes these views use are in App.axaml, so a control laid out on its own keeps them. -->
<!--
The terminal's WebView is collapsed whenever the vault is not unlocked, and that is not a style
@@ -79,186 +62,17 @@
</Border>
<!--
The vault column: hosts above, SSH keys below.
The vault column, in its own control. VaultColumn.axaml carries the reasoning about its shape; what
matters here is that it is the part of this window a test can lay out, because this window as a
whole cannot be shown off the UI thread that owns WebView2.
Two lists in one column rather than a TabControl. A TabControl is the tidier layout and it was not
chosen because of what the terminal does with the keyboard: MainWindow releases focus by calling
Focus() on HostList by name, and a tabbed version would put that target behind a tab selection. This
repository already has one measured finding of that shape — Focus() on a collapsed control is a
no-op and is not replayed when it is revealed, see the note on NativeWebView below — and whether an
unselected TabItem behaves the same way here is untested. Not worth finding out by shipping it, for
a layout preference.
The host list keeps the flexible row, so it is what grows with the window; the key section takes
what it needs and no more.
Wrapped in a Panel rather than bound directly. The column's data context is the vault, and this
element's visibility is the shell's business — put both on one element and IsVisible would resolve
against the vault as well, where IsUnlocked does not exist.
-->
<Grid Grid.Row="1" Grid.Column="0" RowDefinitions="*,Auto,Auto,Auto,Auto,Auto,Auto"
Background="#131722" IsVisible="{Binding IsUnlocked}">
<!-- Named because it is where keyboard focus lands when the user leaves the terminal. -->
<ListBox Grid.Row="0" x:Name="HostList" Margin="6"
ItemsSource="{Binding Vault.Hosts}"
SelectedItem="{Binding Vault.SelectedHost}"
Background="Transparent">
<ListBox.ItemTemplate>
<DataTemplate x:DataType="vm:HostRowViewModel">
<StackPanel Spacing="2" Margin="2,4">
<StackPanel Orientation="Horizontal" Spacing="6">
<TextBlock Text="{Binding Label}" Foreground="#e6e9f0" FontWeight="SemiBold" />
<Border Background="#2b2410" CornerRadius="3" Padding="4,0"
IsVisible="{Binding Badge, Converter={x:Static StringConverters.IsNotNullOrEmpty}}">
<TextBlock Text="{Binding Badge}" Foreground="#e8dcb0" FontSize="10"
VerticalAlignment="Center" />
</Border>
</StackPanel>
<StackPanel Orientation="Horizontal" Spacing="6">
<TextBlock Text="{Binding Address}" Classes="hint" FontSize="11"
FontFamily="ui-monospace,Consolas,monospace" />
<!--
Which of the two ways this host authenticates. In the list because the password box
below is only relevant to one of them, and an empty box on a key-authenticated host is
otherwise indistinguishable from one somebody forgot to fill in.
-->
<TextBlock Text="{Binding Authentication}" Classes="hint" FontSize="11" />
</StackPanel>
</StackPanel>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
<!-- The editor doubles as the "add" form; there is no separate dialog. -->
<Border Grid.Row="1" Padding="10" Background="#171b24" IsVisible="{Binding Vault.IsEditing}">
<StackPanel Spacing="6">
<TextBox Text="{Binding Vault.EditorLabel}" PlaceholderText="name" />
<TextBox Text="{Binding Vault.EditorHostname}" PlaceholderText="hostname or address" />
<NumericUpDown Value="{Binding Vault.EditorPort}" Minimum="1" Maximum="65535"
FormatString="0" />
<TextBox Text="{Binding Vault.EditorUsername}" PlaceholderText="username" />
<TextBox Text="{Binding Vault.EditorNotes}" PlaceholderText="notes" AcceptsReturn="True"
Height="60" TextWrapping="Wrap" />
<!--
Which key this host authenticates with, or a password. Part of the host rather than of the
connection, so it follows the host to every machine; a host bound to a key that has since been
deleted keeps a placeholder entry here, so that editing the port cannot quietly turn it back
into a password host.
-->
<ComboBox ItemsSource="{Binding Vault.EditorKeyChoices}"
SelectedItem="{Binding Vault.EditorSelectedKey}"
HorizontalAlignment="Stretch">
<ComboBox.ItemTemplate>
<DataTemplate x:DataType="vm:SshKeyChoice">
<TextBlock Text="{Binding Label}" />
</DataTemplate>
</ComboBox.ItemTemplate>
</ComboBox>
<CheckBox IsChecked="{Binding Vault.EditorRelayEnabled}"
Content="Allow connecting through the server relay" />
<!--
Stated at the moment the decision is made, which is the only place it means anything. With
relay off the server stores no address at all; with it on the server must be able to resolve
the target, or it becomes an authenticated open proxy into the operator's network.
-->
<TextBlock Classes="hint" FontSize="11"
Text="Enabling the relay stores this host's address on the server in plain text. Everything else about the host stays encrypted." />
<StackPanel Orientation="Horizontal" Spacing="8">
<Button Content="Save" Command="{Binding Vault.SaveHostCommand}" />
<Button Content="Cancel" Command="{Binding Vault.CancelEditCommand}" />
<!--
Withdrawing host key trust lives here, in the host's own settings, because a changed host key
is refused outright with no way to continue past it — so a legitimately rebuilt server needs
somewhere deliberate to be re-approved from, and that somewhere must not be the warning
itself. It takes effect when clicked rather than on Save, and the status line says so; it is
not a field of the host.
Added to this row rather than as a row of its own on purpose: this column's editors already
only just fit at the window's minimum height, which is why only one may be open at a time.
-->
<Button Content="Forget host key" Command="{Binding Vault.ForgetHostKeyCommand}"
IsVisible="{Binding Vault.CanForgetHostKey}"
ToolTip.Tip="Removes the pinned key for this host's address, so the next connection asks you to check its fingerprint again." />
</StackPanel>
</StackPanel>
</Border>
<StackPanel Grid.Row="2" Orientation="Horizontal" Spacing="6" Margin="8"
IsVisible="{Binding !Vault.IsEditing}">
<Button Content="Add" Command="{Binding Vault.NewHostCommand}" />
<Button Content="Edit" Command="{Binding Vault.EditSelectedHostCommand}" />
<Button Content="Delete" Command="{Binding Vault.DeleteHostCommand}" />
</StackPanel>
<Border Grid.Row="3" Padding="8,6" Background="#10141d">
<TextBlock Text="SSH keys" Foreground="#9aa4b6" FontSize="11" FontWeight="SemiBold" />
</Border>
<!--
Bounded rather than flexible, and hidden while its editor is open. The key editor is the tallest
thing in this column — a private key needs a real text area — and at the window's minimum height
there is not room for both. Browsing the list and editing one of its rows are not things anyone
needs to do at the same moment.
-->
<ListBox Grid.Row="4" x:Name="KeyList" Margin="6" MaxHeight="170"
ItemsSource="{Binding Vault.Keys}"
SelectedItem="{Binding Vault.SelectedKey}"
Background="Transparent"
IsVisible="{Binding !Vault.IsEditingKey}">
<ListBox.ItemTemplate>
<DataTemplate x:DataType="vm:SshKeyRowViewModel">
<StackPanel Spacing="2" Margin="2,4">
<StackPanel Orientation="Horizontal" Spacing="6">
<TextBlock Text="{Binding Label}" Foreground="#e6e9f0" FontWeight="SemiBold" />
<Border Background="#2b2410" CornerRadius="3" Padding="4,0"
IsVisible="{Binding Badge, Converter={x:Static StringConverters.IsNotNullOrEmpty}}">
<TextBlock Text="{Binding Badge}" Foreground="#e8dcb0" FontSize="10"
VerticalAlignment="Center" />
</Border>
</StackPanel>
<!--
What is known about the key, never the key. Binding the material here would put a private
key into a list item's visual tree, where a tooltip or a screen reader could read it out.
-->
<TextBlock Text="{Binding Description}" Classes="hint" FontSize="11" />
</StackPanel>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
<Border Grid.Row="5" Padding="10" Background="#171b24"
IsVisible="{Binding Vault.IsEditingKey}">
<StackPanel Spacing="6">
<TextBox Text="{Binding Vault.KeyEditorLabel}" PlaceholderText="name" />
<!--
Not a password box. The armour has to be visible to be pasted and checked — a masked
multi-line box makes "did the whole key arrive?" unanswerable — and the mistake this actually
prevents is pasting the .pub file, which SshKeySecret.TryValidate rejects by name.
-->
<TextBox Text="{Binding Vault.KeyEditorPrivateKey}"
PlaceholderText="-----BEGIN OPENSSH PRIVATE KEY-----"
AcceptsReturn="True" Height="96" TextWrapping="NoWrap"
FontFamily="ui-monospace,Consolas,monospace" FontSize="11" />
<TextBox Text="{Binding Vault.KeyEditorPassphrase}"
PlaceholderText="passphrase, if the key has one" PasswordChar="•" />
<TextBox Text="{Binding Vault.KeyEditorPublicKey}"
PlaceholderText="public half (optional)" FontSize="11" />
<TextBox Text="{Binding Vault.KeyEditorNotes}" PlaceholderText="notes" AcceptsReturn="True"
Height="48" TextWrapping="Wrap" />
<TextBlock Classes="hint" FontSize="11"
Text="The key and its passphrase are encrypted here and never reach the server in a form it can read. Storing both together is the point of a vault: on a disk the passphrase protects the key, and in here your vault passphrase protects both." />
<StackPanel Orientation="Horizontal" Spacing="8">
<Button Content="Save" Command="{Binding Vault.SaveKeyCommand}" />
<Button Content="Cancel" Command="{Binding Vault.CancelKeyEditCommand}" />
</StackPanel>
</StackPanel>
</Border>
<StackPanel Grid.Row="6" Orientation="Horizontal" Spacing="6" Margin="8,4,8,8"
IsVisible="{Binding !Vault.IsEditingKey}">
<Button Content="Add key" Command="{Binding Vault.NewKeyCommand}" />
<Button Content="Edit" Command="{Binding Vault.EditSelectedKeyCommand}" />
<Button Content="Delete" Command="{Binding Vault.DeleteKeyCommand}" />
</StackPanel>
</Grid>
<Panel Grid.Row="1" Grid.Column="0" IsVisible="{Binding IsUnlocked}">
<views:VaultColumn x:Name="VaultPane" DataContext="{Binding Vault}" />
</Panel>
<!-- Terminal column -->
<Grid Grid.Row="1" Grid.Column="1" RowDefinitions="Auto,Auto,*">