DodoTech-Public/DodoSSH
Public Access
3
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Type a path on the SFTP pane, and put a file right without deleting it
ci / build and test (pull_request) Successful in 2m30s
Details
ci / desktop nightly (pull_request) Skipped
Details
ci / android head (pull_request) Successful in 7m21s
Details
ci / api image (pull_request) Successful in 23s
Details
ci / build and test (push) Successful in 2m28s
Details
ci / android head (push) Successful in 3m27s
Details
ci / desktop nightly (push) Successful in 53s
Details
ci / api image (push) Successful in 36s
Details

Browse Source 
Three things the file browser could not do. Somewhere to go had to be walked
to, a file that landed under the wrong name could only be removed and sent
again, and the listing went on showing the directory as it was before this
application put something in it.

◆ THE PATH IS A BOX NOW, not a TextBlock printing where the pane was. A
breadcrumb only reaches what is under the directory already listed, so crossing
a host's filesystem cost a click and a round trip a level, and a path somebody
already knew could not be entered at all. Enter goes; Escape puts back what the
pane is really showing.

What is typed may be absolute, relative to the directory showing, or start at
~ — the four shapes a shell takes, because somebody typing into a box is typing
what they would type into a shell. SftpPath.Resolve turns all of them into one
absolute path, and it resolves them here rather than handing a relative path to
the server: the server would resolve it against the session's own working
directory, which is not necessarily the directory the breadcrumb above the box
is showing. `..` is collapsed textually, which differs from cd through a
symbolic link; the alternative is a realpath round trip before anything lists.

The box holds its own value rather than RemotePath itself. Binding it straight
to the path would navigate on every keystroke — `/`, then `/v`, then `/va` — a
round trip and a failed listing per character. Every other way of moving writes
the real path back into it; a refused listing deliberately does not, because
the path that did not resolve is the one worth having in front of you.

◆ RENAME AND MOVE, and DELETE moves to join them. It had been sitting in the
pane header beside UP and REFRESH — two things that move the pane and one that
destroys a file, in one row — and the three that act on the selected row are
now together in a row of their own, under the name of the row they are about.

One SFTP rename underneath both new operations and two separate questions on
the screen, because the answer is a different kind of thing each time: a rename
takes a name and must not take a path, a move takes a directory and must not
take a name. One box asking for a destination path would be fewer controls and
a worse question — the two mistakes it invites are exactly the ones the split
makes impossible. Each form opens on the answer that changes nothing, so what
gets edited is the half somebody came to change.

Three refusals are made here, and they are the ones a server's message would
not explain: a separator in a name (no such file, about a directory nobody
meant to name), a destination equal to the source (success, and a file that did
not move), and a directory into itself (EINVAL, true and useless). Everything
else is the server's — a name already taken, a path that is not there, a mount
that cannot be crossed — and arrives in the status line in its own words.
Neither is painted in the deletion card's red: a rename is undone by renaming
back, and spending that red twice makes it stop meaning anything.

◆ THE LISTING REFRESHES ITSELF when a transfer lands in it. Both panes, since
an upload lands on the host and a download lands here and either leaves the
pane that is showing that directory a step behind. Only the directory actually
on screen: a queue moving a hundred files elsewhere must not be a round trip
per file for a listing nobody is looking at.

It waits rather than interrupting. Another operation running would have two
listings racing for one collection, and re-listing under an open question is
how the row somebody answered about stops being the row that gets acted on — so
the staleness is remembered and settled at the end of the operation or when the
question is dismissed. It says nothing either way: nobody asked for it, and the
status line at that moment is carrying the news about the transfer. The
selection survives, re-found by path, which is what makes an unasked-for
refresh safe to run under somebody's pointer at all.

◆ THE LAYOUT SUITE FOUND A REAL FAULT and the fix is where the height goes. The
rename form did not fit the 204 pixels the session shell's own sidebar leaves
this pane — MKDIR and the listing were pushed off the bottom. The form is
shorter now (the placeholder says what the box wants, so there is no field
label above it), and the item row and the breadcrumb step aside while any of
the three questions is up, which is what the phone head already did with its
own buttons.

Measuring also settled something the markup had been claiming and is not true:
at that width the listing collapses to nothing under any of the three cards,
the deletion card included, and has done since the sidebar arrived. So "the row
it is about is still on screen" is retired from the deletion card's remark, and
the full path each card carries is what identifies the row instead. Recorded
where it is drawn rather than left to be rediscovered.

TESTS. SftpPath.Resolve gets the four shapes, ~ with and without a home to
expand it to, a blank box, and climbing past the root. ShellFlowTests gets nine
against a session that records what it was asked to do — which path was
renamed, which directories were listed — rather than against the sentence this
code writes about itself: the path box absolute and relative, rename in place,
the separator refusal, a move by relative path, the no-op refusal, the three
questions displacing each other, and the three rules the automatic refresh
follows. The local half is in TransferQueueingTests, where a real folder
answers. Two new shapes are measured, and the deletion card's own measurement
moves to the connected state — the only state it can be asked in, and the
narrow one.

What the tests cannot reach is in docs/manual-checks.md as phase 2b: a real
server's cross-device and name-taken refusals, and a soft keyboard, which is
why the phone's path box has a GO button rather than trusting whatever the IME
decided to draw on its return key.
This commit is contained in:
jaap-jan committed 2026-08-21 12:05:33 +02:00
1 parent 2f8daacb60
commit 882f01c515
11 files changed
+1508 -50
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

src/DodoSSH.Client.App/Views/TransfersScreen.axaml
+145 -28
View File
@@ -327,10 +327,12 @@
<!-- ==== The host ==== -->
<!--
Six rows rather than five: the connection's own strip is the new one, and it is inside this pane
rather than above both because it is about this pane and nothing else.
Seven rows. Two of them are furniture over a listing rather than part of it: the connection's own
strip, and the row of things that can be done to whichever row is chosen. Both are inside this pane
rather than above both panes because both are about this one and nothing else. The two questions —
deleting, and renaming or moving — share a single row, since only one of the two is ever on screen.
-->
<Grid Grid.Column="2" x:Name="RemotePane" RowDefinitions="Auto,Auto,Auto,Auto,Auto,*"
<Grid Grid.Column="2" x:Name="RemotePane" RowDefinitions="Auto,Auto,Auto,Auto,Auto,Auto,*"
DragDrop.AllowDrop="True">
<!--
@@ -344,25 +346,42 @@
distinct glyphs; see that pane's own remark on why the pair differs without the actions differing.
-->
<!--
The path is alone in the star column for the reason the local pane's header remark spells out:
TextTrimming needs the finite width only a star column gives it, and this is the pane where the
long path is not even unusual — it is any host with a deep directory tree.
◆ THE PATH IS TYPED HERE, and that is what the star column is now holding.
It was a TextBlock printing where the pane was. A breadcrumb only reaches what is under the
directory already listed, so crossing a host's filesystem was a walk to the common ancestor and
back down — a click and a round trip a level — and a path somebody already knew could not be
entered at all. Enter goes; Escape puts back what the pane is really showing. See
TransfersViewModel.RemotePathDraft for why the box holds its own value rather than RemotePath
itself, and SftpPath.Resolve for what an entry that is not absolute means.
Still alone in the star column, for the reason the local pane's header remark spells out: this box
has to be bounded, and an Auto column beside a StackPanel would measure it at its content's width
and push the buttons past the pane's edge.
DELETE has left this row. It acts on the selected row rather than on the pane, and it is one of
three that do now — see the item row below, which is where the three of them are together and
where there is room for three rather than for one.
-->
<Border Grid.Row="0" Padding="0,0,0,10" BorderThickness="0">
<Grid ColumnDefinitions="Auto,*,Auto">
<StackPanel Grid.Column="0" Orientation="Horizontal" Spacing="12" VerticalAlignment="Center"
Margin="0,0,12,0">
Margin="0,0,8,0">
<TextBlock Classes="label" FontSize="10" Text="HOST" VerticalAlignment="Center"
IsVisible="{Binding ShowsHostPicker}" />
<TextBlock Classes="label" FontSize="10" Text="BUCKET" VerticalAlignment="Center"
IsVisible="{Binding ShowsBucketPicker}" />
</StackPanel>
<TextBlock Grid.Column="1" Classes="mono" FontSize="13.5" FontWeight="Medium"
Foreground="{StaticResource TextDim}" VerticalAlignment="Center"
HorizontalAlignment="Left"
Text="{Binding RemotePath}" TextTrimming="CharacterEllipsis"
ToolTip.Tip="{Binding RemotePath}" />
<StackPanel Grid.Column="2" Orientation="Horizontal" Spacing="4" Margin="12,0,0,0">
<TextBox Grid.Column="1" Classes="pathbox" VerticalAlignment="Center"
Text="{Binding RemotePathDraft}" IsEnabled="{Binding IsConnected}"
PlaceholderText="/path/to/somewhere"
ToolTip.Tip="Type a path and press Enter. A relative path is taken from here; ~ is the account's home directory.">
<TextBox.KeyBindings>
<KeyBinding Gesture="Enter" Command="{Binding GoToTypedRemotePathCommand}" />
<KeyBinding Gesture="Escape" Command="{Binding RevertTypedRemotePathCommand}" />
</TextBox.KeyBindings>
</TextBox>
<StackPanel Grid.Column="2" Orientation="Horizontal" Spacing="4" Margin="8,0,0,0">
<Button Classes="paneicon" Command="{Binding RemoteUpCommand}"
IsEnabled="{Binding IsConnected}" ToolTip.Tip="Up one directory">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="16" Text="&#xE5DB;" />
@@ -371,10 +390,6 @@
IsEnabled="{Binding IsConnected}" ToolTip.Tip="Refresh">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="16" Text="&#xE5D5;" />
</Button>
<Button Classes="paneicon danger" Command="{Binding DeleteRemoteCommand}"
IsEnabled="{Binding CanDeleteRemote}" ToolTip.Tip="Delete on the host">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE872;" />
</Button>
</StackPanel>
</Grid>
</Border>
@@ -402,9 +417,53 @@
</Border>
<!--
The question DELETE asks. Under the button rather than over the pane, so the row it is about is
still on screen and still selected while it is being answered — and it names the full path rather
than the file, because a name is the half that does not identify anything.
◆ WHAT CAN BE DONE TO THE ROW THAT IS CHOSEN. Only while something is connected.
Three buttons in one place, which is the point. DELETE used to sit alone in the pane header beside
UP and REFRESH — two things that move the pane and one that destroys a file, in one row — and
there was no rename and no move at all, so a file that had landed under the wrong name could only
be put right by deleting it and sending it again. These three act on the selection, so they belong
together and away from the two that act on the pane.
The name beside them is the row they are about, ellipsized. It says which row rather than which
path: the listing directly underneath has that row highlighted, so a full path here would be
repeating what the selection is already showing. The forms the buttons open do print the path,
because that is the moment something is committed rather than merely looked at.
The row goes while one of the three questions is up rather than sitting there greyed out, and so
does the breadcrumb below it — see ShowsRemoteItemActions. The form that opens is the answer to
what these buttons asked, and inside the session shell this pane is 204 pixels wide: the height
goes to the question or to the buttons that raised it, not to both.
-->
<Border Grid.Row="2" Padding="12,5" BorderBrush="{StaticResource BorderSubtle}"
BorderThickness="0,0,0,1" IsVisible="{Binding ShowsRemoteItemActions}">
<Grid ColumnDefinitions="*,Auto">
<TextBlock Grid.Column="0" Classes="mono" FontSize="11.5" VerticalAlignment="Center"
Foreground="{StaticResource TextFaint}" TextTrimming="CharacterEllipsis"
Text="{Binding SelectedRemoteName}" />
<StackPanel Grid.Column="1" Orientation="Horizontal" Spacing="4" Margin="8,0,0,0">
<Button Classes="paneicon" Command="{Binding RenameRemoteCommand}"
IsEnabled="{Binding CanRenameRemote}" ToolTip.Tip="Rename on the host">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE9AD;" />
</Button>
<Button Classes="paneicon" Command="{Binding MoveRemoteCommand}"
IsEnabled="{Binding CanMoveRemote}" ToolTip.Tip="Move to another directory">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE675;" />
</Button>
<Button Classes="paneicon danger" Command="{Binding DeleteRemoteCommand}"
IsEnabled="{Binding CanDeleteRemote}" ToolTip.Tip="Delete on the host">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE872;" />
</Button>
</StackPanel>
</Grid>
</Border>
<!--
The question DELETE asks. It names the full path rather than the file, because a name is the half
that does not identify anything — and that is now the whole of how the question says which row it
is about: at the session shell's own 204-pixel width there is no height left for a listing under
it, so "the row is still on screen and still selected" is no longer true and the path in the card
is what carries the identity. See the rename form below, which is measured in the same shape.
This is the strongest warning on any of these screens, and deliberately: everything else this
application deletes is a tombstone against a copy the server still has, and a file on somebody's
@@ -415,7 +474,7 @@
CANCEL side by side want closer to 220, so at the narrow width they wrap onto their own line
instead of one of them going off the edge, which the WrapPanel achieves for free.
-->
<Border Grid.Row="2" Padding="12,10" Background="{StaticResource DangerWash}"
<Border Grid.Row="3" Padding="12,10" Background="{StaticResource DangerWash}"
BorderBrush="{StaticResource DangerSoft}" BorderThickness="0,0,0,1"
IsVisible="{Binding IsConfirmingRemoteDeletion}">
<StackPanel Spacing="7">
@@ -435,7 +494,65 @@
</StackPanel>
</Border>
<Grid Grid.Row="3" ColumnDefinitions="*,Auto" Margin="12,6,12,4">
<!--
◆ RENAME AND MOVE, in the row the deletion question uses and never at the same time as it.
One form for both, because they differ only in what the box starts out holding and in the words
around it — see RemoteMoveRequest, where both sets are chosen. It shares this Grid row with
the deletion card above: the three questions are mutually exclusive by construction, each one's
own opening clearing the others, so a row of its own would be a row that is empty whenever this
one is not.
It is not painted in the deletion card's danger colours, and that is deliberate rather than an
oversight. A rename is undone by renaming back; the deletion beside it is the one thing this
application does that nothing can walk back, and spending the same red on both would make the red
stop meaning anything.
Enter commits from inside the box, which is where the hands already are once an answer has been
typed.
◆ IT TAKES THE WHOLE PANE at the session shell's own 204-pixel width, and that is measured rather
than hoped: the listing's star row is squeezed to nothing while either question is open, exactly
as the deletion card above already squeezed it. There is no room for a form and a listing in 336
pixels, and the form carries the full path precisely so the row underneath does not have to be
visible for the question to be about something identifiable. That is why the item row and the
breadcrumb step aside instead — the height they free is what keeps the form itself un-clipped,
which is what ScreenLayoutTests measures.
-->
<Border Grid.Row="3" Padding="12,10" Background="{StaticResource Raised}"
BorderBrush="{StaticResource BorderSubtle}" BorderThickness="0,0,0,1"
IsVisible="{Binding IsMovingRemote}">
<StackPanel Spacing="7">
<TextBlock Classes="heading" FontSize="14" TextWrapping="Wrap"
Text="{Binding PendingRemoteMove.Question}" />
<SelectableTextBlock Classes="mono" FontSize="11.5" TextWrapping="Wrap"
Foreground="{StaticResource TextFaint}"
Text="{Binding PendingRemoteMove.FullPath}" />
<TextBox Text="{Binding RemoteMoveTarget}"
PlaceholderText="{Binding PendingRemoteMove.FieldHint}">
<TextBox.KeyBindings>
<KeyBinding Gesture="Enter" Command="{Binding ConfirmMoveRemoteCommand}" />
<KeyBinding Gesture="Escape" Command="{Binding CancelMoveRemoteCommand}" />
</TextBox.KeyBindings>
</TextBox>
<TextBlock Classes="hint" FontSize="11.5" TextWrapping="Wrap"
Text="{Binding PendingRemoteMove.Note}" />
<WrapPanel>
<Button Classes="accent" Content="{Binding PendingRemoteMove.ConfirmLabel}" Margin="0,0,8,4"
Command="{Binding ConfirmMoveRemoteCommand}" IsEnabled="{Binding !IsBusy}" />
<Button Classes="ghost" Content="CANCEL" Margin="0,0,0,4"
Command="{Binding CancelMoveRemoteCommand}" />
</WrapPanel>
</StackPanel>
</Border>
<!--
Away while a question is up, for the reason the item row above states: the trail is where the pane
is and MKDIR makes a directory, and neither is what somebody answering a question about one row
is doing.
-->
<Grid Grid.Row="4" ColumnDefinitions="*,Auto" Margin="12,6,12,4"
IsVisible="{Binding !IsAskingAboutRemoteEntry}">
<ItemsControl Grid.Column="0" ItemsSource="{Binding RemoteTrail}" VerticalAlignment="Center">
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
@@ -480,14 +597,14 @@
48 pixels rather than the drawer's own wider habit, and SIZE/MODIFIED shrink to match the local
pane's narrower numbers. See the local pane's own remark on why 204 rather than the design's 1920.
-->
<Grid Grid.Row="4" ColumnDefinitions="20,*,56,52,48" Margin="0,2,10,4">
<Grid Grid.Row="5" ColumnDefinitions="20,*,56,52,48" Margin="0,2,10,4">
<TextBlock Grid.Column="1" Classes="label" Text="NAME" FontSize="9.5" Margin="8,0,8,0" />
<TextBlock Grid.Column="2" Classes="label" Text="SIZE" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="3" Classes="label" Text="MODIFIED" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="4" Classes="label" Text="PERMS" FontSize="9.5" HorizontalAlignment="Right" />
</Grid>
<ListBox Grid.Row="5" x:Name="RemoteList" Classes="filerows" ItemsSource="{Binding RemoteEntries}"
<ListBox Grid.Row="6" x:Name="RemoteList" Classes="filerows" ItemsSource="{Binding RemoteEntries}"
SelectedItem="{Binding SelectedRemoteEntry}">
<ListBox.ItemTemplate>
<DataTemplate x:DataType="vm:RemoteEntryRowViewModel">
@@ -513,7 +630,7 @@
A directory with nothing in it. It no longer has to say anything about not being connected: that
state is the invitation below, which covers this pane whole.
-->
<TextBlock Grid.Row="5" Classes="hint" FontSize="12" Margin="24" MaxWidth="300"
<TextBlock Grid.Row="6" Classes="hint" FontSize="12" Margin="24" MaxWidth="300"
HorizontalAlignment="Center" VerticalAlignment="Center" TextAlignment="Center"
Text="Nothing in this directory." IsVisible="{Binding !HasRemoteEntries}" />
@@ -535,7 +652,7 @@
the picker arrives, so the tall shape is the form rather than form-plus-prose, and neither shape
reaches the floor. Anything added here has to hold that; the layout suite measures both.
-->
<Border Grid.Row="1" Grid.RowSpan="5" Background="{StaticResource Canvas}"
<Border Grid.Row="1" Grid.RowSpan="6" Background="{StaticResource Canvas}"
IsVisible="{Binding !IsConnected}">
<StackPanel Spacing="10" Margin="20" MaxWidth="320"
HorizontalAlignment="Center" VerticalAlignment="Center">
@@ -679,11 +796,11 @@
window that has stopped answering, and the answer arriving after the drop is the answer arriving
too late. See the local pane for why neither may hit-test.
-->
<Border Grid.Row="0" Grid.RowSpan="6" IsHitTestVisible="False"
<Border Grid.Row="0" Grid.RowSpan="7" IsHitTestVisible="False"
Background="{StaticResource AccentWash}" BorderBrush="{StaticResource Accent}"
BorderThickness="2" IsVisible="{Binding IsRemoteDropTarget}" />
<Border Grid.Row="0" Grid.RowSpan="6" IsHitTestVisible="False"
<Border Grid.Row="0" Grid.RowSpan="7" IsHitTestVisible="False"
Background="{StaticResource DangerWash}" BorderBrush="{StaticResource DangerSoft}"
BorderThickness="2" IsVisible="{Binding IsRemoteDropRefused}">
<TextBlock Classes="hint" Text="Connect to a host first." FontSize="12"