Public Access
jaap-jan
aff776cb42
Six defects, all found by running this head on an emulator against a local API rather than by reading it. They are in one commit because two of the files carry several of them and splitting those would mean hand-editing patches; each is argued at its own site. ── the keypad, which is most of this ─────────────────────────────────────────────────────────────────── It was eleven 30-by-44 keys in a horizontal ScrollViewer, and it was wrong twice over. A pan and a press begin with the same few pixels of travel, so a thumb coming down at an angle — which is how a thumb comes down — was read as the start of a pan and the press was never delivered; the row slid slightly instead. And 30 tall is well under the 48 Android asks for, so the presses that did arrive were hard to aim. The arrows, the keys pressed most and in sequence, were the ones parked past the right-hand edge. Termux, Termius, JuiceSSH, ConnectBot and Blink all ship this row and not one of them scrolls it: they divide the width evenly and add a second row when the set does not fit. That is not convention for its own sake — a key whose position is fixed can be hit without looking, which is the whole point of a modifier row used while reading the output above it. So: two UniformGrid rows, every key an equal share of the width, nothing scrollable, 40 tall. Every key kept. Arrows on the lower row where the thumb rests, reordered to ← ↓ ↑ → so the pairs that undo each other are neighbours. It costs about 51 pixels of terminal, four or five lines, and that is the right trade: the row that was cheaper did not work. The keys also gain a pressed state, which they had none of. They are Focusable="False" so that using one does not take the keyboard off the terminal, and a button that never takes focus never shows the adorner Fluent would otherwise give it — leaving no feedback at all on a control whose only job is to be pressed. Their looks move from assignments in the code-behind to Button.hotkey, which is what lets a style say :pressed, and the Ctrl latch becomes a class rather than two brushes written by hand. ── and five smaller ones ──────────────────────────────────────────────────────────────────────────────── The keyboard's inset was never cleared when the app was resumed without the keyboard it was applied for. Android takes the keyboard away as the activity stops and Avalonia's input pane raises no StateChanged, the pane going with the window rather than closing in front of one — so the interface came back holding a whole keyboard's height of empty canvas. 838 of 2340 pixels on a Pixel 5, on every screen, until something opened and closed the keyboard. MainActivity now raises PhoneEnvironment.Resumed and PhoneShell re-asks the pane. It asks rather than assuming zero: a permission prompt or the biometric sheet can hand the activity back with the keyboard genuinely still up, and flattening the inset there would strand the focused box under a real one. TextBlock.detail never wrapped, where .body beside it always has. A block that neither wraps nor trims lays out at its full single-line width and the parent clips it, with no ellipsis to say anything is missing — so the add sheet read "A machine to connect to, filed under a group if you" and stopped. Which of the fifty-odd .detail blocks overflows is a function of width and font scale rather than of the string, so this is a style rather than an attribute on the handful visibly wrong on one phone. The nine that genuinely want one line now say NoWrap beside their TextTrimming, which is the pairing that was always meant. The two port boxes are NumericUpDowns and were the only unthemed controls on this head — Fluent's border and fill, next to a TextBox.field sharing their row. App.axaml has styled NumericUpDown for the desktop all along; this head never had one. Three buttons classed "icon accent" were painting Fluent's own Button.accent, #6275AC, a blue in no palette here. The desktop overrides that style and this head did not, so the same class read correctly there and not here. The host key sheet said "First contact with 10.0.2.2 · 2222 . Nothing in this keychain…" — Avalonia puts a space between adjacent Runs and the last one began with the full stop. A gap before a full stop, on the one dialogue whose whole job is to be read carefully before it is answered. ── checks ────────────────────────────────────────────────────────────────────────────────────────────── manual-checks gains 10.4a and 11.10f. 10.4 already covered dismissing the keyboard with back or the chevron but not leaving the app with it up, which is the path the inset bug shipped through; 10.4a covers both directions, since a fix that flattened the inset on every resume would pass one half and fail the other. 11.10f guards the keypad against a ScrollViewer being put back around it.
748 lines
45 KiB
XML
748 lines
45 KiB
XML
<UserControl xmlns="https://github.com/avaloniaui"
|
||
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
|
||
xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
|
||
xmlns:views="using:DodoSSH.Client.Android.Views"
|
||
x:Class="DodoSSH.Client.Android.Views.TerminalScreen"
|
||
x:DataType="vm:MainWindowViewModel"
|
||
Background="{StaticResource Canvas}">
|
||
|
||
<!--
|
||
Design 03 — TERMINAL.
|
||
|
||
One WebView for every session, exactly as on the desktop and for the same reason: each session is a pane
|
||
inside the one page, so switching tabs is a single frame rather than a second browser. On a phone the
|
||
argument is stronger — a WebView per tab would be several hundred megabytes on a device that will
|
||
reclaim them.
|
||
|
||
The tab strip is horizontal-scrolling rather than wrapping. Wrapping would reflow the terminal every
|
||
time a tab opened, which is the one thing a terminal must not do while output is arriving.
|
||
|
||
── the screen a shell gets ───────────────────────────────────────────────────────────────────────────
|
||
A connected phone shows one bar and then the terminal. The vault header, the shells strip and the
|
||
three-entry bottom bar are all collapsed by PhoneShell while a shell is showing, and what replaces them
|
||
is the row below: back, the sessions, and the way to open another one.
|
||
|
||
With nothing running it is only the header and the strip. This surface is then the connect page below —
|
||
a box and the machines connected to before — which is not what the screen was being cleared for, and is
|
||
the one screen reachable by closing your last tab, so the nav stays. See PhoneShell.RefreshChrome.
|
||
|
||
That is a trade, and the thing bought is the only one a terminal really wants. At 360dp the chrome this
|
||
screen used to sit inside came to 254 pixels of a roughly 780-pixel display — a third of it — and every
|
||
one of those rows was about somewhere the user was not. What is given up is the bottom bar's one-tap
|
||
reach to Hosts, Keychain and MORE; back and the + between them lead to all of it, and the system back
|
||
gesture does the same thing the arrow does.
|
||
-->
|
||
|
||
<UserControl.Styles>
|
||
|
||
<!--
|
||
── the connecting step list ─────────────────────────────────────────────────────────────────────
|
||
The same five rows the desktop's ConnectingCard draws, from the same reported phases, in this head's
|
||
own sizes. Kept here rather than in Phone.axaml because nothing else on this head has a step list —
|
||
the theme file is for what more than one screen shares, and a rule that exists for one control is
|
||
easier to read beside it.
|
||
|
||
Amber for the step in flight, green behind it, red where it stopped. That is the palette's rule
|
||
rather than an exception to it: green is what is true and purple is what you can press, and a step
|
||
still happening is neither. See ConnectingCard.axaml for the longer version of this argument, and
|
||
Palette.axaml for the rule itself.
|
||
|
||
A phone needs this more than a desktop does, which is the same thing the connecting block below
|
||
already says about itself: mobile links are slower and drop more often, so the stretch this describes
|
||
is longer here and more likely to end badly.
|
||
-->
|
||
<!--
|
||
Its own FontFamily rather than the row also carrying the mono class, which is this head's convention
|
||
and not a stylistic preference: Phone.axaml's mono sets a colour and a size along with the family, so
|
||
a caption wearing both classes would be asking two rules for one Foreground and settling it on style
|
||
ordering. Every other text class here — body, label, title, detail — names its own family for exactly
|
||
that reason. The desktop's mono sets the family alone, which is why ConnectingCard composes the two
|
||
and this does not.
|
||
-->
|
||
<Style Selector="TextBlock.stepcaption">
|
||
<Setter Property="FontFamily" Value="{StaticResource MonoFont}" />
|
||
<Setter Property="Foreground" Value="{StaticResource TextFaint}" />
|
||
<Setter Property="FontSize" Value="11" />
|
||
<Setter Property="VerticalAlignment" Value="Center" />
|
||
</Style>
|
||
<Style Selector="TextBlock.stepcaption.done">
|
||
<Setter Property="Foreground" Value="{StaticResource TextDim}" />
|
||
</Style>
|
||
<Style Selector="TextBlock.stepcaption.running">
|
||
<Setter Property="Foreground" Value="{StaticResource WarnText}" />
|
||
<Setter Property="FontWeight" Value="SemiBold" />
|
||
</Style>
|
||
<Style Selector="TextBlock.stepcaption.stopped">
|
||
<Setter Property="Foreground" Value="{StaticResource DangerText}" />
|
||
</Style>
|
||
|
||
<!-- Fixed width and centred: four different characters on a ragged edge is a list that looks broken. -->
|
||
<Style Selector="TextBlock.stepmark">
|
||
<Setter Property="Foreground" Value="{StaticResource BorderMid}" />
|
||
<Setter Property="FontSize" Value="11" />
|
||
<Setter Property="Width" Value="13" />
|
||
<Setter Property="TextAlignment" Value="Center" />
|
||
<Setter Property="VerticalAlignment" Value="Center" />
|
||
</Style>
|
||
<Style Selector="TextBlock.stepmark.done">
|
||
<Setter Property="Foreground" Value="{StaticResource Live}" />
|
||
</Style>
|
||
<Style Selector="TextBlock.stepmark.running">
|
||
<Setter Property="Foreground" Value="{StaticResource Warn}" />
|
||
</Style>
|
||
<Style Selector="TextBlock.stepmark.stopped">
|
||
<Setter Property="Foreground" Value="{StaticResource Danger}" />
|
||
</Style>
|
||
|
||
<!--
|
||
4 rather than the desktop's 5, which is the only deliberate difference between the two heads here:
|
||
this bar sits in a column 24 from each edge of a 360dp screen rather than under a 460-wide card, so
|
||
the same height reads as a heavier rule across a narrower span.
|
||
-->
|
||
<Style Selector="ProgressBar.steptrack">
|
||
<Setter Property="Height" Value="4" />
|
||
<Setter Property="MinHeight" Value="4" />
|
||
<Setter Property="CornerRadius" Value="2" />
|
||
<Setter Property="Background" Value="{StaticResource Chip}" />
|
||
<Setter Property="Foreground" Value="{StaticResource Warn}" />
|
||
</Style>
|
||
<Style Selector="ProgressBar.steptrack.stopped">
|
||
<Setter Property="Foreground" Value="{StaticResource Danger}" />
|
||
</Style>
|
||
|
||
</UserControl.Styles>
|
||
|
||
<Panel>
|
||
|
||
<!--
|
||
Four rows since the disconnect strip arrived. It is Auto and empty except while the selected tab's shell
|
||
has stopped, so an ordinary session pays nothing for it — and when it is up it takes its height off the
|
||
renderer rather than drawing over it, which on this head is not optional either: the renderer is a native
|
||
child view composited above everything Avalonia draws, so a banner over its rectangle would be invisible.
|
||
-->
|
||
<Grid RowDefinitions="Auto,*,Auto,Auto">
|
||
|
||
<!-- ============ the bar ============ -->
|
||
<!--
|
||
Everything the phone draws above a shell. It is a bar rather than a strip because it now carries the
|
||
two controls the collapsed chrome took with it, one at each end, with the sessions between them.
|
||
|
||
Both are outside the ScrollViewer deliberately. They are the way out of this surface and the way to
|
||
another host, and a tenth tab must not be able to push either of them off the right-hand edge.
|
||
|
||
35 tall, a third off the 52 it opened at. Every height inside it came down with it — the icon squares
|
||
to 34, the pills to 30 — because a bar that shrank around controls that did not would only have moved
|
||
the clipping somewhere harder to see.
|
||
-->
|
||
<!-- DeepChrome rather than Chrome, since v5: this bar is what the vault header, the strip and the
|
||
bottom bar collapse into while a shell is showing, so it takes their surface along with their
|
||
job — see the remark on the header in PhoneShell.axaml. -->
|
||
<Border Grid.Row="0" Height="35" Background="{StaticResource DeepChrome}"
|
||
BorderBrush="{StaticResource Border}" BorderThickness="0,0,0,1">
|
||
<Grid ColumnDefinitions="Auto,*,Auto">
|
||
|
||
<!--
|
||
Back, and it goes to the page this terminal was opened over rather than to Hosts by name. The
|
||
system back gesture already does exactly that — see PhoneShell.axaml.cs — and an arrow that
|
||
landed somewhere else would be the second of two answers to one question.
|
||
|
||
Height overridden and width left alone. Button.icon is a 44 square, which is taller than this bar;
|
||
the 44 that matters is the horizontal one, since nothing in a row of this shape is hard to hit
|
||
above or below.
|
||
-->
|
||
<Button Grid.Column="0" Classes="icon" Content="←" Height="34" Margin="4,0,0,0"
|
||
Command="{Binding ShowScreenCommand}" CommandParameter="{Binding Screen}" />
|
||
|
||
<!--
|
||
v2 draws these as pills rather than as a segmented strip, so the row is transparent and each
|
||
session carries its own outline. The close cross moved inside the pill with the name, which is
|
||
what makes it read as one object you can dismiss rather than as two adjacent targets.
|
||
-->
|
||
<ScrollViewer Grid.Column="1" HorizontalScrollBarVisibility="Auto"
|
||
VerticalScrollBarVisibility="Disabled">
|
||
<ItemsControl ItemsSource="{Binding Tabs}" Margin="6,0" VerticalAlignment="Center">
|
||
<ItemsControl.ItemsPanel>
|
||
<ItemsPanelTemplate><StackPanel Orientation="Horizontal" Spacing="6" /></ItemsPanelTemplate>
|
||
</ItemsControl.ItemsPanel>
|
||
<ItemsControl.ItemTemplate>
|
||
<DataTemplate x:DataType="vm:TerminalTabViewModel">
|
||
<!--
|
||
30 tall, in a bar of 35. It was 44, and the argument for 44 was that a pill you only
|
||
select can be chip-sized while one containing the control that ends a shell cannot — the
|
||
close cross is the one control on this head that is both destructive and has neither
|
||
confirmation nor undo. That argument is now carried by width rather than by height: the
|
||
cross keeps its full 44-pixel column, and what it lost is 14 pixels of vertical slack in a
|
||
row where nothing sits above or below it to be hit by mistake.
|
||
-->
|
||
<Border Background="{StaticResource Panel}" BorderBrush="{StaticResource BorderMid}"
|
||
BorderThickness="1" CornerRadius="10" Height="30">
|
||
<StackPanel Orientation="Horizontal">
|
||
<Button Classes="row" MinHeight="28" Padding="11,0" CornerRadius="10"
|
||
VerticalContentAlignment="Center"
|
||
Command="{Binding $parent[views:TerminalScreen].((vm:MainWindowViewModel)DataContext).SelectTabCommand}"
|
||
CommandParameter="{Binding}">
|
||
<StackPanel Orientation="Horizontal" Spacing="7" VerticalAlignment="Center">
|
||
<!--
|
||
Green only while there is a shell behind it, amber while one is being made, and
|
||
red where a connection broke rather than a shell exiting; see the same dot in
|
||
PhoneShell, and Phone.axaml for why neither of the last two is a rule broken.
|
||
-->
|
||
<Ellipse Classes="dot" Classes.live="{Binding IsLive}"
|
||
Classes.connecting="{Binding IsConnecting}"
|
||
Classes.dropped="{Binding IsDropped}" Width="6" Height="6"
|
||
VerticalAlignment="Center" />
|
||
<TextBlock Classes="mono" FontSize="12" FontWeight="SemiBold"
|
||
Text="{Binding Label}" />
|
||
</StackPanel>
|
||
</Button>
|
||
<!--
|
||
The close cross is inside the tab, which the plan calls out: a strip-level close would
|
||
act on whichever tab happened to be selected, and on a phone that is a mis-tap away from
|
||
killing the wrong shell.
|
||
|
||
The hairline down its left edge is not decoration. The two targets are flush inside one
|
||
pill, so without a visible seam there is nothing telling a thumb where "switch to this
|
||
shell" stops and "end it" starts.
|
||
|
||
Both alignments are stated, and the vertical one is not decoration either: Button.row
|
||
sets HorizontalContentAlignment and says nothing about the other axis, so the cross
|
||
was sitting against the top of its own column rather than in the middle of the pill.
|
||
It reads as a misprint, which for the control that ends a session is the wrong thing
|
||
to look like.
|
||
-->
|
||
<Button Classes="row" MinHeight="28" Width="44" Padding="0" CornerRadius="0,10,10,0"
|
||
HorizontalContentAlignment="Center" VerticalContentAlignment="Center"
|
||
BorderBrush="{StaticResource BorderMid}" BorderThickness="1,0,0,0"
|
||
Command="{Binding $parent[views:TerminalScreen].((vm:MainWindowViewModel)DataContext).CloseTabCommand}"
|
||
CommandParameter="{Binding}">
|
||
<TextBlock Text="×" Foreground="{StaticResource TextFaint}" FontSize="14"
|
||
HorizontalAlignment="Center" VerticalAlignment="Center"
|
||
TextAlignment="Center" />
|
||
</Button>
|
||
</StackPanel>
|
||
</Border>
|
||
</DataTemplate>
|
||
</ItemsControl.ItemTemplate>
|
||
</ItemsControl>
|
||
</ScrollViewer>
|
||
|
||
<!--
|
||
Another connection, and the three kinds this application can make. A menu rather than a straight
|
||
jump to Hosts because SFTP and S3 used to be two taps through the bottom bar's MORE, and the bar
|
||
is not on screen here — so the control that replaces it has to lead to all three or it has quietly
|
||
removed two of them.
|
||
|
||
The desktop's own + refuses a flyout on this reasoning, in TerminalTabs.axaml: a popup dropping
|
||
into the renderer's rectangle may or may not composite above a native child window, and that is
|
||
not a claim to make without a screenshot. It is answered here rather than dodged — this is a sheet
|
||
at the bottom of the screen and opening it collapses the renderer outright, exactly as the
|
||
palette does on the desktop. Nothing is drawn over the WebView.
|
||
|
||
Plain Button.icon, the same as the arrow across from it, rather than the accent variant. The two
|
||
are a matched pair at either end of one bar — one leaves this surface, one adds to it — and an
|
||
accented + would rank itself above the way out. The accent fill belongs to the floating + on
|
||
HOSTS, which is the only action on its screen; this one is not.
|
||
|
||
Click as well as Command, and the handler does one thing the command cannot: put the software
|
||
keyboard away. See OnConnectMenuRequested.
|
||
-->
|
||
<Button Grid.Column="2" Classes="icon" Content="+" Height="34" Margin="0,0,4,0"
|
||
Click="OnConnectMenuRequested"
|
||
Command="{Binding OpenConnectSheetCommand}" />
|
||
</Grid>
|
||
</Border>
|
||
|
||
<!-- ============ the renderer ============ -->
|
||
<Panel Grid.Row="1">
|
||
|
||
<!--
|
||
============ nothing open ============
|
||
|
||
Not an empty state any more, and that is what the bottom bar's word change is about: with no shell
|
||
running this surface is where a connection is made rather than a page apologising for having
|
||
nothing on it. Two things are offered, in the order somebody reaches for them.
|
||
|
||
A box, because the case this application had no answer for is the address somebody has just been
|
||
given. Everything else here starts from a keychain item, which is right for a machine used twice and
|
||
is several screens of work for one used once.
|
||
|
||
And the machines already connected to, under it, because that is the commoner half by far: the
|
||
thing most likely to be wanted is the thing that was wanted yesterday. They come out of the vault's
|
||
own connection log — see MainWindowViewModel.RecentConnections — so they survive a restart and
|
||
arrive on a new phone with the keychain, which a list kept in this process would not.
|
||
-->
|
||
<ScrollViewer IsVisible="{Binding !HasTabs}">
|
||
<StackPanel Margin="20,18,20,24" Spacing="10">
|
||
|
||
<TextBlock Classes="title" FontSize="13" Text="CONNECT TO A MACHINE" />
|
||
|
||
<!--
|
||
The manual target. One box in the grammar people already have — user@host, or user@host:port —
|
||
rather than three, because three boxes on a phone is three taps between three keyboards for
|
||
something that arrives as one string.
|
||
-->
|
||
<TextBox Classes="field" Text="{Binding Vault.ManualTarget}"
|
||
PlaceholderText="user@host or user@host:port">
|
||
<TextBox.KeyBindings>
|
||
<KeyBinding Gesture="Enter" Command="{Binding Vault.ConnectManuallyCommand}" />
|
||
</TextBox.KeyBindings>
|
||
</TextBox>
|
||
|
||
<!--
|
||
A typed password and nothing else. Offering the keychain's keys here would be a second binding
|
||
resolution beside the one the connect path already has, and a key is the reason to save the
|
||
machine as a host rather than dial it from a box.
|
||
|
||
Classes="secret" and not merely PasswordChar: the class is what also tells the software keyboard
|
||
this is not prose, which is the difference between dots on screen and dots on screen with the
|
||
password in the IME's dictionary. See Theme/Phone.axaml.
|
||
-->
|
||
<TextBox Classes="field secret" Text="{Binding Vault.ManualPassword}"
|
||
PlaceholderText="password">
|
||
<TextBox.KeyBindings>
|
||
<KeyBinding Gesture="Enter" Command="{Binding Vault.ConnectManuallyCommand}" />
|
||
</TextBox.KeyBindings>
|
||
</TextBox>
|
||
|
||
<Button Classes="primary" Content="CONNECT" Command="{Binding Vault.ConnectManuallyCommand}" />
|
||
|
||
<!--
|
||
Beside the box rather than on the shell's status line. What fails here is about what was typed —
|
||
a missing account, a port that is not a number — and a sentence about a text box belongs under
|
||
the text box.
|
||
-->
|
||
<TextBlock Classes="detail" TextWrapping="Wrap" Foreground="{StaticResource WarnText}"
|
||
Text="{Binding Vault.ManualStatus}"
|
||
IsVisible="{Binding Vault.ManualStatus, Converter={x:Static StringConverters.IsNotNullOrEmpty}}" />
|
||
|
||
<TextBlock Classes="body"
|
||
Text="Nothing typed here is saved. A machine worth keeping belongs on HOSTS, where it can carry a key, a group's defaults and a name." />
|
||
|
||
<!-- ============ where you have been ============ -->
|
||
<StackPanel Spacing="2" Margin="0,14,0,0" IsVisible="{Binding HasRecentConnections}">
|
||
|
||
<TextBlock Classes="label" Text="RECENT" Margin="0,0,0,4" />
|
||
|
||
<ItemsControl ItemsSource="{Binding RecentConnections}">
|
||
<ItemsControl.ItemTemplate>
|
||
<DataTemplate x:DataType="vm:ConnectionLogRowViewModel">
|
||
<!--
|
||
Tapping one does not connect, and that is deliberate rather than a missing step. A row
|
||
that names a keychain host goes to that host with its connect bar — which is where its
|
||
key, or its password box, or its refusal lives — and one that names only an address goes
|
||
back into the box above, without the password, which was never stored. Either way what
|
||
happens next is visible before anything is dialled. See ConnectToRecentCommand.
|
||
-->
|
||
<Button Classes="row" MinHeight="52" Padding="12,8" CornerRadius="10"
|
||
Command="{Binding $parent[views:TerminalScreen].((vm:MainWindowViewModel)DataContext).ConnectToRecentCommand}"
|
||
CommandParameter="{Binding}">
|
||
<Grid ColumnDefinitions="*,Auto">
|
||
<StackPanel Grid.Column="0" Spacing="2" VerticalAlignment="Center">
|
||
<TextBlock Classes="mono" FontSize="13" FontWeight="SemiBold"
|
||
Text="{Binding HostLabel}" TextTrimming="CharacterEllipsis" />
|
||
<TextBlock Classes="detail" FontSize="10.5" Text="{Binding Address}"
|
||
TextWrapping="NoWrap" TextTrimming="CharacterEllipsis" />
|
||
</StackPanel>
|
||
<TextBlock Grid.Column="1" Classes="detail" FontSize="10"
|
||
VerticalAlignment="Center" Text="{Binding Started}" />
|
||
</Grid>
|
||
</Button>
|
||
</DataTemplate>
|
||
</ItemsControl.ItemTemplate>
|
||
</ItemsControl>
|
||
</StackPanel>
|
||
|
||
<TextBlock Classes="body" Margin="0,10,0,0"
|
||
Text="A shell opened here keeps running while the app is in the background, and keeps running after the keychain is locked — a notification says so for as long as one is alive." />
|
||
|
||
</StackPanel>
|
||
</ScrollViewer>
|
||
|
||
<!--
|
||
A tab with no pane behind it: one still connecting, or one that was refused. The desktop head draws
|
||
the same thing in its own ConnectingCard, and it exists for the same reason — connecting does not
|
||
hold the application still any more, so there is a stretch in which a tab is selected and there is
|
||
nothing yet to render in it. A phone needs it more than a desktop does: mobile links are slower, and
|
||
the alternative is a black rectangle.
|
||
|
||
It carries the address, which is where that fact went when the connection line was folded into the
|
||
bar above. This is the moment it is worth reading — what is being dialled, before anything has
|
||
answered — and once a shell is open its own prompt says the same thing more accurately than a header
|
||
derived from the keychain ever did.
|
||
-->
|
||
<StackPanel IsVisible="{Binding IsConnectingShowing}" VerticalAlignment="Center" Margin="24"
|
||
Spacing="10">
|
||
<TextBlock Classes="title" FontSize="13" Text="{Binding SelectedTab.Label}" />
|
||
<TextBlock Classes="detail" FontSize="11" Foreground="{StaticResource TextDim}"
|
||
TextWrapping="Wrap" Text="{Binding SelectedTab.Address}" />
|
||
|
||
<!--
|
||
Where a single unchanging "connecting…" used to be. The track counts steps that really finished
|
||
against the five there are — StepsDone over StepCount, never a percentage, because the arithmetic
|
||
that makes a percentage is the arithmetic that starts inventing one. See TerminalTabViewModel.
|
||
|
||
Drawn for both states rather than once per state: a refused connection has the same five rows and
|
||
the same track, and the only differences are that one row is red and the track stops where it got
|
||
to. Two templates kept identical for the sake of a colour is how the two drift apart.
|
||
-->
|
||
<ProgressBar Classes="steptrack" Classes.stopped="{Binding SelectedTab.IsFailed}"
|
||
Minimum="0" Maximum="{Binding SelectedTab.StepCount}"
|
||
Value="{Binding SelectedTab.StepsDone, Mode=OneWay}" />
|
||
|
||
<ItemsControl ItemsSource="{Binding SelectedTab.Steps}">
|
||
<ItemsControl.ItemsPanel>
|
||
<ItemsPanelTemplate>
|
||
<StackPanel Spacing="6" />
|
||
</ItemsPanelTemplate>
|
||
</ItemsControl.ItemsPanel>
|
||
<ItemsControl.ItemTemplate>
|
||
<DataTemplate x:DataType="vm:ConnectionStepViewModel">
|
||
<StackPanel Orientation="Horizontal" Spacing="9">
|
||
<TextBlock Classes="stepmark"
|
||
Classes.done="{Binding IsDone}"
|
||
Classes.running="{Binding IsRunning}"
|
||
Classes.stopped="{Binding IsStopped}"
|
||
Text="{Binding Mark}" />
|
||
<TextBlock Classes="stepcaption"
|
||
Classes.done="{Binding IsDone}"
|
||
Classes.running="{Binding IsRunning}"
|
||
Classes.stopped="{Binding IsStopped}"
|
||
Text="{Binding Caption}" />
|
||
</StackPanel>
|
||
</DataTemplate>
|
||
</ItemsControl.ItemTemplate>
|
||
</ItemsControl>
|
||
|
||
<!--
|
||
Only for a refusal now. While a connection is being made this used to be the whole of what this
|
||
screen said, and it is now the step list's running row said twice — so it is shown for the one
|
||
state the list cannot put into words: why it stopped.
|
||
-->
|
||
<TextBlock Classes="body" Text="{Binding SelectedTab.Status}"
|
||
Foreground="{StaticResource Danger}"
|
||
IsVisible="{Binding SelectedTab.IsFailed}" />
|
||
|
||
<!--
|
||
Two 44-high targets side by side rather than one, and the second is the logs: the step list is
|
||
this attempt and the log is every other one, which is the question a connection that is taking too
|
||
long on a mobile link actually raises — has this machine ever worked from here. Reached the
|
||
ordinary way, through ShowScreenCommand, exactly as the rail and MORE reach it.
|
||
-->
|
||
<StackPanel Orientation="Horizontal" Spacing="8" HorizontalAlignment="Left">
|
||
<!--
|
||
Only for a refusal, and it runs the same command the disconnect strip below the renderer does —
|
||
the vault's own connect path, back into this same tab. Worth more on a phone than on a desk: the
|
||
commonest refusal here is a mobile link that was not up yet, and the alternative is going back
|
||
to the hosts screen to find a machine whose name is already on this card.
|
||
-->
|
||
<Button Classes="row" MinHeight="44" Padding="14,0"
|
||
Command="{Binding ReconnectTabCommand}" CommandParameter="{Binding SelectedTab}"
|
||
IsEnabled="{Binding CanReconnectSelectedTab, FallbackValue=False}"
|
||
IsVisible="{Binding SelectedTab.IsFailed}">
|
||
<TextBlock Classes="label" FontSize="9" Text="TRY AGAIN" />
|
||
</Button>
|
||
<Button Classes="row" MinHeight="44" Padding="14,0"
|
||
Command="{Binding CloseTabCommand}" CommandParameter="{Binding SelectedTab}">
|
||
<TextBlock Classes="label" FontSize="9" Text="CLOSE THIS TAB" />
|
||
</Button>
|
||
<Button Classes="row" MinHeight="44" Padding="14,0"
|
||
Command="{Binding ShowScreenCommand}"
|
||
CommandParameter="{x:Static vm:ShellScreen.Logs}">
|
||
<TextBlock Classes="label" FontSize="9" Text="SHOW LOGS" />
|
||
</Button>
|
||
</StackPanel>
|
||
</StackPanel>
|
||
|
||
<!--
|
||
Collapsed rather than merely covered when there is no pane to show. On Windows this control is a
|
||
native child view that composites above everything Avalonia draws, which is why the desktop head
|
||
hides it explicitly; whether Android's WebView does the same is recorded as unverified in
|
||
docs/android-port.md. Hiding it either way costs nothing and is correct under both answers.
|
||
|
||
IsTerminalShowing rather than HasTabs, which are no longer the same question: a tab that is still
|
||
connecting has no pane, and showing the renderer for it would show the previous session's output
|
||
under the name of a machine nothing has connected to yet. It is also what the connect sheet turns
|
||
off — see MainWindowViewModel.IsTerminalShowing.
|
||
|
||
v2 insets this behind a 14-pixel radius. Not done, and not an oversight: this is a native child view
|
||
composited above everything Avalonia draws, so a rounded Border behind it clips nothing — the
|
||
corners would stay square over a frame pretending otherwise. What the design was really after is
|
||
that the terminal reads as the lit surface, and that comes from its own background, which now is the
|
||
design's #171A26. See WebAssets/terminal.css.
|
||
-->
|
||
<NativeWebView x:Name="Renderer" IsVisible="{Binding IsTerminalShowing, FallbackValue=False}" />
|
||
|
||
<!--
|
||
============ the keyboard ============
|
||
|
||
One pixel in the corner, drawn never, and it is where every character typed into a shell on this
|
||
phone arrives. ADR 0015 has the whole argument; the short of it is that a software keyboard over a
|
||
terminal has to be told to stop autocorrecting, and on Android the only setting that works is an
|
||
inputType on a native input connection — which a page inside a WebView cannot reach and an Avalonia
|
||
control can, on the version already pinned here.
|
||
|
||
Not stretched over the renderer, which would be the obvious shape and is wrong three times: the
|
||
WebView composites above everything Avalonia paints so it would be invisible, it would never see the
|
||
touches the WebView consumes first, and it would sit over the connect page that shares this Panel
|
||
whenever no session is open. Focus does not need area. Taps on the terminal are noticed by
|
||
RendererFocus, where they actually land.
|
||
|
||
Collapsed with the renderer, on the same binding and for a reason of its own: a focusable control is
|
||
a tab stop and a focus candidate wherever it lives, and this Panel is also the connect page when no
|
||
session is open. Left always-visible it would be a stray target on a screen with a real text box on
|
||
it, offering a keyboard configured for a shell to somebody typing a hostname.
|
||
-->
|
||
<views:TerminalInputSurface x:Name="Input"
|
||
IsVisible="{Binding IsTerminalShowing, FallbackValue=False}" />
|
||
</Panel>
|
||
|
||
<!-- ============ accessory keys ============ -->
|
||
<!--
|
||
The row every Android SSH client ships, and the reason is not preference: a software keyboard has no
|
||
Ctrl, no Esc, no Tab and no arrows, and without them a phone cannot interrupt a process, complete a
|
||
path, or reach the previous command. Ctrl and Alt latch — pressed once they apply to the next key and
|
||
then release, because holding a modifier while typing is not possible one-thumbed.
|
||
-->
|
||
<!-- Only with a pane to type into: the keys send bytes at a session, and a connecting tab has none. -->
|
||
<!--
|
||
◆ TWO FIXED ROWS THAT FILL THE WIDTH, AND NOTHING HERE SCROLLS. THAT IS THE WHOLE CHANGE.
|
||
|
||
What this replaced was one 33-pixel row holding eleven 30-by-44 keys inside a horizontal ScrollViewer,
|
||
and it was wrong in two ways that compounded each other.
|
||
|
||
── the scroller was eating the presses ──────────────────────────────────────────────────────────────
|
||
A horizontally scrollable strip and a row of buttons want opposite things from the same gesture. Every
|
||
tap starts as a press and a few pixels of travel, and a ScrollViewer that can pan claims exactly that:
|
||
a thumb coming down at an angle — which is how a thumb comes down — is read as the start of a pan, the
|
||
button never sees a click, and the row slides slightly instead. Pressing a key and having the keys
|
||
move is the single most confidence-destroying thing a keyboard can do, and it happened often enough
|
||
to be the first thing anybody noticed about this row.
|
||
|
||
── and the keys were too small to hit anyway ─────────────────────────────────────────────────────────
|
||
30 tall. Android's own minimum touch target is 48 and every accessory row in every terminal on the
|
||
platform is somewhere near it. The height had been taken down from 38 to save a strip of terminal,
|
||
which is a trade worth making right up until the control stops working, and 30 is past that.
|
||
|
||
── what the other clients do, because all of them agree ─────────────────────────────────────────────
|
||
Termux, Termius, JuiceSSH, ConnectBot and Blink all ship this row and not one of them scrolls it.
|
||
They divide the width evenly between a fixed set of keys and, where the set does not fit, they use a
|
||
second row — Termux ships two by default. That is not convention for its own sake: a key whose
|
||
position is fixed can be hit without looking, which is the entire point of a modifier row you use
|
||
while reading the output above it. A key that might have scrolled has to be found first.
|
||
|
||
So: two rows, every key stretched to an equal share of the width, none of it scrollable, and 40 tall
|
||
instead of 30. Nothing was dropped — all eleven keys are here, and the four that mattered most are the
|
||
ones that benefit, because the arrows were the keys living past the right edge.
|
||
|
||
── what it costs, stated rather than buried ─────────────────────────────────────────────────────────
|
||
About 51 pixels of terminal, which is four or five lines of output. That is a real price and it is the
|
||
right one: the row that was cheaper did not work, and a terminal with five more lines and no reachable
|
||
Ctrl is not the better surface.
|
||
|
||
── the split ────────────────────────────────────────────────────────────────────────────────────────
|
||
Modifiers and punctuation on top, cursor keys underneath. The arrows go on the lower row because they
|
||
are the keys pressed repeatedly and in sequence — history, then along the line — so they want the row
|
||
the thumb rests nearest, and there are only four of them, which leaves them the widest targets on the
|
||
whole keypad. The text-size buttons ride at that row's right-hand end, outside the flex.
|
||
|
||
The five pixels above the whole thing are a gap and not a border. The renderer is a native child view,
|
||
so nothing Avalonia draws can sit on top of it — a hairline between the two would have to be a row of
|
||
its own — and a terminal whose last line of output is flush against a row of grey keys reads as one
|
||
surface that has gone wrong rather than as two that are different things.
|
||
-->
|
||
<!-- ============ what a terminal says once its shell has stopped ============ -->
|
||
<!--
|
||
The phone's half of SessionEndedBar, and it needs it more than the desk does: a mobile link drops on
|
||
its own, the screen goes off, and the tab that went quiet is discovered later with no idea whether the
|
||
shell was exited or cut off. So it names which, prints the sentence that came with it, and offers the
|
||
one useful answer.
|
||
|
||
Two lines rather than the desktop's one, because 360dp cannot hold a word, a sentence and two buttons
|
||
across. The word and the buttons share the top line — the buttons are where a thumb already is — and
|
||
the sentence wraps underneath at two lines maximum, which is enough for anything sshd or a socket
|
||
error actually says and short of a strip that eats the terminal.
|
||
|
||
RECONNECT is disabled rather than hidden when there is nothing to dial: a machine typed in by hand has
|
||
no keychain entry to redial, and a control visibly refusing answers "why not" better than an absent one.
|
||
See MainWindowViewModel.CanReconnectSelectedTab.
|
||
-->
|
||
<Border Grid.Row="2" Background="{StaticResource DeepChrome}"
|
||
BorderBrush="{StaticResource Border}" BorderThickness="0,1,0,0" Padding="16,8"
|
||
IsVisible="{Binding SessionEndedText, Converter={x:Static StringConverters.IsNotNullOrEmpty}, FallbackValue=False}">
|
||
<StackPanel Spacing="6">
|
||
|
||
<Grid ColumnDefinitions="*,Auto">
|
||
<StackPanel Grid.Column="0" Orientation="Horizontal" Spacing="7" VerticalAlignment="Center">
|
||
<Ellipse Classes="dot" Classes.dropped="{Binding IsSessionDropped}" Width="7" Height="7"
|
||
VerticalAlignment="Center" />
|
||
<TextBlock Classes="label" FontSize="9" Text="{Binding SessionEndedText}" />
|
||
</StackPanel>
|
||
|
||
<StackPanel Grid.Column="1" Orientation="Horizontal" Spacing="8">
|
||
<Button Classes="row" MinHeight="40" Padding="12,0"
|
||
Command="{Binding ReconnectTabCommand}" CommandParameter="{Binding SelectedTab}"
|
||
IsEnabled="{Binding CanReconnectSelectedTab, FallbackValue=False}">
|
||
<TextBlock Classes="label" FontSize="9" Text="RECONNECT" />
|
||
</Button>
|
||
<Button Classes="row" MinHeight="40" Padding="12,0"
|
||
Command="{Binding CloseTabCommand}" CommandParameter="{Binding SelectedTab}">
|
||
<TextBlock Classes="label" FontSize="9" Text="CLOSE" />
|
||
</Button>
|
||
</StackPanel>
|
||
</Grid>
|
||
|
||
<TextBlock Classes="detail" FontSize="10.5" Foreground="{StaticResource TextDim}"
|
||
TextWrapping="Wrap" MaxLines="2" TextTrimming="CharacterEllipsis"
|
||
Text="{Binding SessionEndedDetail}"
|
||
IsVisible="{Binding SessionEndedDetail, Converter={x:Static StringConverters.IsNotNullOrEmpty}}" />
|
||
|
||
</StackPanel>
|
||
</Border>
|
||
|
||
<Border Grid.Row="3" IsVisible="{Binding IsTerminalShowing}" Margin="0,5,0,0">
|
||
<StackPanel Spacing="4">
|
||
|
||
<!--
|
||
Modifiers and punctuation. Populated from the table in the code-behind, which is also where the
|
||
bytes each one sends live; a UniformGrid rather than a StackPanel so the seven divide the width
|
||
between them instead of taking what their labels happen to need — "ctrl" is four characters and
|
||
"|" is one, and on a row of keys those two want the same target, not proportional ones.
|
||
-->
|
||
<UniformGrid x:Name="AccessoryKeys" Columns="7" Margin="8,0" />
|
||
|
||
<!--
|
||
The cursor keys, and the two text-size buttons riding at the end.
|
||
|
||
Grid rather than a second UniformGrid across the whole width: the arrows share what is left after
|
||
A− and A+ have taken their fixed 44 each, so the four of them flex and the two of them do not.
|
||
Putting all six in one uniform row would make the font buttons as wide as an arrow key and move
|
||
them every time the row's contents changed.
|
||
-->
|
||
<Grid ColumnDefinitions="*,Auto" Margin="8,0">
|
||
|
||
<UniformGrid x:Name="ArrowKeys" Grid.Column="0" Columns="4" />
|
||
|
||
<!--
|
||
The text-size buttons.
|
||
|
||
They used to have a row of their own above the terminal, on the argument that the accessory row
|
||
scrolls and these two must never be off-screen — a terminal too small to read is exactly the
|
||
state in which hunting for the control that fixes it is worst. Nothing on this keypad scrolls
|
||
any more, so that argument is now satisfied by construction rather than by placement.
|
||
|
||
A phone cannot press Ctrl+plus. The desktop head has that chord and needs no buttons; this head
|
||
has no keyboard to press it with, which is why the two heads differ here and nowhere else in
|
||
this screen.
|
||
|
||
Disabled at the ends rather than clamping silently. A button that keeps accepting taps and does
|
||
nothing reads as the terminal having stopped responding, which is the one thing this screen must
|
||
never look like.
|
||
|
||
◆ Focusable="False", for the reason the accessory keys carry in code — see
|
||
TerminalScreen.axaml.cs. Every button on this keypad sits over a terminal somebody is typing
|
||
into, and an ordinary one takes Avalonia's focus off the input surface on tap. Making the text
|
||
smaller must not cost the keyboard.
|
||
-->
|
||
<!-- No Spacing: Button.hotkey carries a 2-pixel side margin, so the gaps here match the
|
||
UniformGrid cells' without being counted twice. -->
|
||
<StackPanel Grid.Column="1" Orientation="Horizontal" Margin="8,0,0,0">
|
||
<Border Width="1" Height="20" Background="{StaticResource Border}" Margin="0,0,4,0"
|
||
VerticalAlignment="Center" />
|
||
|
||
<Button Classes="hotkey" Width="44" Focusable="False"
|
||
Command="{Binding ShrinkTerminalFontCommand}"
|
||
IsEnabled="{Binding CanShrinkTerminalFont}">
|
||
<TextBlock Classes="mono" FontSize="13" Text="A−" />
|
||
</Button>
|
||
|
||
<Button Classes="hotkey" Width="44" Focusable="False"
|
||
Command="{Binding EnlargeTerminalFontCommand}"
|
||
IsEnabled="{Binding CanEnlargeTerminalFont}">
|
||
<TextBlock Classes="mono" FontSize="15" Text="A+" />
|
||
</Button>
|
||
</StackPanel>
|
||
</Grid>
|
||
</StackPanel>
|
||
</Border>
|
||
|
||
</Grid>
|
||
|
||
<!-- ============ the connect sheet ============ -->
|
||
<!--
|
||
Follows the add sheet on HostsScreen, which follows HostKeySheet: a scrim, a bottom-aligned panel with
|
||
the top two corners rounded, and a grab handle that is decoration. Dismissible, like the add sheet and
|
||
unlike the host-key one — "which kind of connection" has no wrong answer and no answer at all is one
|
||
of them.
|
||
|
||
It lives here rather than in PhoneShell for the reason the add sheet lives in its own screen: nothing
|
||
but this surface raises it. The scrim reaching only the screen area is the full display while a shell
|
||
is showing, because the bottom bar is collapsed for it. Raised from the connect page it is not, and
|
||
that lands on the add sheet's own answer: the three destinations under the scrim stay tappable, and for
|
||
a menu of places to connect from, navigating away is a perfectly good way to decide not to.
|
||
|
||
Every row navigates away from the terminal. That is not a side effect of the menu, it is the menu:
|
||
each of the three destinations is a picker, and the shell they open lands back on this surface as a
|
||
new tab in the bar above.
|
||
-->
|
||
<Panel IsVisible="{Binding IsConnectSheetOpen}">
|
||
|
||
<!--
|
||
Declared before the sheet so the sheet draws over it: a Panel stacks its children in declaration
|
||
order. See the .scrim style for why a tap on it must not light anything up.
|
||
-->
|
||
<Button Classes="scrim" Command="{Binding CloseConnectSheetCommand}" />
|
||
|
||
<Border VerticalAlignment="Bottom" Background="{StaticResource Panel}"
|
||
BorderBrush="{StaticResource BorderMid}" BorderThickness="0,1,0,0"
|
||
CornerRadius="22,22,0,0" Padding="20,18,20,16">
|
||
<StackPanel Spacing="0">
|
||
|
||
<Border Width="38" Height="4" CornerRadius="2" Background="{StaticResource BorderMid}"
|
||
HorizontalAlignment="Center" Margin="0,0,0,16" />
|
||
|
||
<TextBlock Classes="title" Text="CONNECT" FontSize="13" />
|
||
|
||
<Button Classes="row" Margin="0,10,0,0" Command="{Binding ShowScreenCommand}"
|
||
CommandParameter="{x:Static vm:ShellScreen.Hosts}">
|
||
<StackPanel Spacing="3" VerticalAlignment="Center">
|
||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="Connect" />
|
||
<TextBlock Classes="detail" FontSize="10.5"
|
||
Text="Another shell, on this host or any other in the keychain." />
|
||
</StackPanel>
|
||
</Button>
|
||
|
||
<!--
|
||
These two go through ShowFiles rather than ShowScreen, as the MORE hub's own rows do: one screen
|
||
over one view model, and which kind of remote it offers is the thing being chosen. It can refuse
|
||
— there is a single transfer session behind both — and refusing lands on the screen the open one
|
||
belongs to with a sentence saying why, which is a better place to read it than a sheet that has
|
||
just closed.
|
||
-->
|
||
<Button Classes="row" Command="{Binding ShowFilesCommand}"
|
||
CommandParameter="{x:Static vm:RemoteKind.Host}">
|
||
<StackPanel Spacing="3" VerticalAlignment="Center">
|
||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="Connect via SFTP" />
|
||
<TextBlock Classes="detail" FontSize="10.5" Text="Browse a host's files." />
|
||
</StackPanel>
|
||
</Button>
|
||
|
||
<Button Classes="row" Command="{Binding ShowFilesCommand}"
|
||
CommandParameter="{x:Static vm:RemoteKind.Bucket}">
|
||
<StackPanel Spacing="3" VerticalAlignment="Center">
|
||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="Connect via S3" />
|
||
<TextBlock Classes="detail" FontSize="10.5"
|
||
Text="Objects in an S3-compatible bucket from the keychain." />
|
||
</StackPanel>
|
||
</Button>
|
||
|
||
<Button Classes="secondary" Content="CANCEL" Margin="0,12,0,0"
|
||
Command="{Binding CloseConnectSheetCommand}" />
|
||
|
||
</StackPanel>
|
||
</Border>
|
||
</Panel>
|
||
|
||
</Panel>
|
||
|
||
</UserControl>
|