Public Access
jaap-jan
4300d917a8
Connecting held the vault's busy gate, which meant a window that did nothing visible for as long as a machine took to answer — and against one that is merely asleep, that is the whole timeout. The gate is gone from that one command. A tab now appears in the strip in the same turn as the click, carrying "connecting…" rather than a pane, and the terminal's rectangle draws a card naming the host and the address being dialled. Every other screen stays usable, and two connections can be in flight at once. That splits the vault's one connection event into three, carrying an attempt id, because "which tab is this about" can no longer be answered by "the most recent one". The id also buys the two kinds of not-connecting their different endings: a refusal stays in the strip as a tab holding its reason, since by then the user is quite likely three screens away and a status line they are not looking at is not where a failure should end; a host key question takes the tab away and puts the window back on HOSTS, because the prompt is drawn there and a tab claiming failure would be competing with the thing about to resume it. ConnectAsync takes no CancellationToken any more, and that is load-bearing rather than tidying. A [RelayCommand] over a method that takes one generates a command that cancels the previous execution's token on every invocation — so asking for a second machine silently abandoned the first, measured as the first tab disappearing with "Cancelled." the instant the second was asked for. Giving up on a connection is closing its tab, and a session that lands after that is adopted rather than dropped: a shell running with nothing naming it cannot be closed at all. A tab is marked active on IsShowing rather than IsSelected. The selection survives navigating away — that is what makes the strip a way back to a terminal instead of a way to lose one — so a tab lit while preferences filled the window was a second "you are here" mark pointing at something nobody could see. The nav rail's own entries have always made this distinction. The host list grows the two gestures it looked like it already had. A right click selects the row under the pointer before opening a menu of Connect, Edit and Delete — the menu is on the list rather than in the item template, so its entries are the vault's own commands and not a row's, and it is cancelled outright over a group heading. Dragging a host onto a heading files it there, onto a host files it beside that one, and onto UNGROUPED takes it out of a group; the write is one field of one host through the same repository a save uses, refused while the editor is open because a drop is a gesture on the list and not on a half-typed form. Clicking a result in the palette connects, which is what a list of hosts under a search box looks like it does. It went through the shell's own command, so the pointer and Enter take one path. And the files screen's two pickers followed the vault's lists once, at unlock: a host or a bucket created afterwards could not be picked until the keychain had been locked and opened again, with nothing on screen explaining why the machine plainly in the host list was missing. They follow the collections now, re-finding the selection by id across the rebuild a sync pass causes every minute. 165 shell tests and 69 layout tests green, including the connecting tab, both failure endings, two connections at once, a connection in flight across a lock, and the right click acting on the row under the pointer rather than on the selection. The drag itself is in docs/manual-checks.md with the rest of phase 7 — headless Avalonia has no platform drag, and a test that claimed to have dropped something would pass while confirming nothing.
78 lines
4.4 KiB
XML
78 lines
4.4 KiB
XML
<UserControl xmlns="https://github.com/avaloniaui"
|
|
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
|
|
xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
|
|
x:Class="DodoSSH.Client.App.Views.ConnectingCard"
|
|
x:DataType="vm:MainWindowViewModel"
|
|
Background="{StaticResource Canvas}">
|
|
|
|
<!--
|
|
What the terminal's rectangle holds while the selected tab has no pane: a connection being made, or one
|
|
that was refused.
|
|
|
|
It exists because connecting stopped blocking the window. The tab appears the moment the user asks for
|
|
it and the handshake runs behind it, so there is a stretch — seconds against a machine that is asleep,
|
|
longer against one that is not there — in which a tab is selected and there is nothing to show in it.
|
|
Showing the last terminal's pane would be a lie, and showing nothing reads as the application having
|
|
broken, so this says which machine, as whom, and how far along it is.
|
|
|
|
It obeys the occlusion rule the whole window obeys: this is Avalonia-drawn content in the WebView's own
|
|
rectangle, so the shell collapses the terminal while it is up. IsTerminalShowing and IsConnectingShowing
|
|
are exclusive by construction — a selected tab either has a session or it does not — which is what makes
|
|
that safe rather than merely arranged. See MainWindow.axaml.
|
|
|
|
In its own file rather than in the window, like every other card here, because nothing inside that window
|
|
can be laid out by a test: WebView2's adapter refuses the headless session's thread.
|
|
-->
|
|
|
|
<Panel>
|
|
<StackPanel VerticalAlignment="Center" HorizontalAlignment="Center" Spacing="14" MaxWidth="460"
|
|
Margin="24">
|
|
|
|
<StackPanel Spacing="6" HorizontalAlignment="Center">
|
|
<TextBlock Classes="mono" Text="{Binding SelectedTab.Label}" FontSize="15" FontWeight="Medium"
|
|
Foreground="{StaticResource Text}" HorizontalAlignment="Center"
|
|
TextTrimming="CharacterEllipsis" />
|
|
<TextBlock Classes="mono" Text="{Binding SelectedTab.Address}" FontSize="10.5"
|
|
Foreground="{StaticResource TextFaint}" HorizontalAlignment="Center"
|
|
TextTrimming="CharacterEllipsis" />
|
|
</StackPanel>
|
|
|
|
<!--
|
|
Two states, deliberately different. Waiting is an accent line under the host's name; a refusal is
|
|
the reason, in the palette's red, because it is the only place the reason will be after the user
|
|
navigates away from the screen that started the connection.
|
|
-->
|
|
<TextBlock Classes="mono" Text="{Binding SelectedTab.Status}" FontSize="11"
|
|
Foreground="{StaticResource Accent}" HorizontalAlignment="Center"
|
|
TextWrapping="Wrap" TextAlignment="Center"
|
|
IsVisible="{Binding SelectedTab.IsConnecting}" />
|
|
|
|
<SelectableTextBlock Text="{Binding SelectedTab.Status}" FontSize="12"
|
|
Foreground="{StaticResource Danger}" HorizontalAlignment="Center"
|
|
TextWrapping="Wrap" TextAlignment="Center"
|
|
IsVisible="{Binding SelectedTab.IsFailed}" />
|
|
|
|
<TextBlock Classes="hint" FontSize="10.5" TextAlignment="Center" HorizontalAlignment="Center"
|
|
Text="Nothing else is waiting for this. Every other screen still works, and the strip above says how this one is getting on."
|
|
IsVisible="{Binding SelectedTab.IsConnecting}" />
|
|
|
|
<!--
|
|
The same command the tab's own cross runs, named for what pressing it means in each of the two
|
|
states. On a connecting tab it is how the attempt is given up on: the shell forgets it, and a
|
|
handshake that finishes afterwards is adopted rather than dropped — see
|
|
MainWindowViewModel.CloseTabAsync. Two buttons rather than one with a converted label, because the
|
|
two are different decisions and only one of them abandons something still running.
|
|
-->
|
|
<Button Classes="ghost" HorizontalAlignment="Center" Content="GIVE UP"
|
|
Command="{Binding CloseTabCommand}" CommandParameter="{Binding SelectedTab}"
|
|
IsVisible="{Binding SelectedTab.IsConnecting}" />
|
|
|
|
<Button Classes="ghost" HorizontalAlignment="Center" Content="CLOSE TAB"
|
|
Command="{Binding CloseTabCommand}" CommandParameter="{Binding SelectedTab}"
|
|
IsVisible="{Binding SelectedTab.IsFailed}" />
|
|
|
|
</StackPanel>
|
|
</Panel>
|
|
|
|
</UserControl>
|