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

Merge branch 'main' into the group's move and its deletion question

Browse Source 
Main took the group's EDIT and DELETE off the GROUPS heading while this branch
was adding a MOVE beside them, so the conflict was about the same six pixels
from both directions. Main's answer wins outright, and it is the better one for
the reason its own message gives: a button beside a heading has no card under a
pointer to mean, and had to work its subject out from the selection or from the
trail. Moving a group had that problem worst of all — the thing it takes with it
is everything on the shelf, and "which shelf" is not a question a button there
could answer plainly.

So the MOVE button is gone and the menu entry it was drawn beside is the whole
of it. That entry was already in this branch, above the separator DELETE sits
below, and it needed no change: the card menu selects whatever was right-clicked
before it runs anything, which is exactly the aiming a group move wants.

Three things went with the button. ShowsGroupActions, which main deleted because
hiding buttons was all it did, and which this branch had extended to hide them
for the move panel as well. CanMoveGroupTarget, which existed to answer whether
that button was worth drawing — CanMoveSelectedHost stays, because the phone
really does leave the host's MOVE out rather than offer a refusal, and a menu
whose entries came and went would be a menu whose items move. And the two test
assertions that read them, which were describing the button rather than the
behaviour; what they were guarding is that the two panels never share the
moment, and IsConfirmingGroupDeletion says that directly.

The move panel and the deletion question both keep their place under the
heading, which is where the buttons were and is now simply where that section
puts things. They still exclude each other, by disarming rather than by a
visibility flag: MoveGroup clears a pending deletion and DeleteGroup folds the
move panel away.

Manual checks 3.3 was rewritten by main for the menu and by this branch for the
tick, and now says both; 3.3a is new and walks a two-level shelf across a vault
boundary, which is the half of this feature no headless test can watch land.
This commit is contained in:
jaap-jan
2026-08-04 17:11:06 +02:00
parent a86731ee08 6fad84c484
commit 780f4bf892
38 changed files with 3416 additions and 165 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/DodoSSH.Client.App/Views/HostDrawer.axaml
+2 -2
View File
@@ -569,8 +569,8 @@
<!--
◆ WHICH VAULT THIS GROUP WILL LIVE IN, on the same terms as the host editor's picker
above: asked while adding, hidden where there is only one vault to write to, and never
offered for an existing group. Not because the group is stuck — MOVE over the group cards
takes it to another vault, with everything on the shelf — but because moving it is a
offered for an existing group. Not because the group is stuck — the card's own menu takes
it to another vault, with everything on the shelf — but because moving it is a
re-seal of every item involved into new ids, which is nothing a SAVE on this form could
do, and a picker here would do it as a side effect of correcting a default port.
src/DodoSSH.Client.App/Views/HostsScreen.axaml
+22 -37
View File
@@ -226,32 +226,15 @@
</ItemsControl.ItemTemplate>
</ItemsControl>
<Grid ColumnDefinitions="Auto,*,Auto">
<TextBlock Grid.Column="0" Classes="label" Text="GROUPS"
Foreground="{StaticResource TextDim}" VerticalAlignment="Center" />
<!--
The group's own actions, beside the group cards rather than in the toolbar, because they act
on the card that is selected — and this is where the selection is made. Hidden rather than
disabled while either panel below is up, as every other row of buttons in this application
is, so none of them can be pressed twice, and hidden again when there is nothing for them to
act on. What that is, with no card selected, is the group the trail above ends with; see
VaultViewModel.GroupTarget.
MOVE is between them rather than beside DELETE, and it stays visible with nowhere to go: the
command answers with a sentence naming the reason, which is more use than a button that has
quietly gone. The host pane's ⋯ menu keeps its own entry on the same reasoning.
-->
<StackPanel Grid.Column="2" Orientation="Horizontal" Spacing="6">
<Button Classes="ghost" Content="EDIT" Command="{Binding EditGroupCommand}"
IsVisible="{Binding ShowsGroupActions}" />
<Button Classes="ghost" Content="MOVE" Command="{Binding MoveGroupCommand}"
IsVisible="{Binding ShowsGroupActions}"
ToolTip.Tip="Moves this group to another vault, with the groups inside it and every host filed under them." />
<Button Classes="ghost" Content="DELETE" Command="{Binding DeleteGroupCommand}"
IsVisible="{Binding ShowsGroupActions}" />
</StackPanel>
</Grid>
<!--
The heading and nothing else. This used to be a row with EDIT and DELETE at the far end of it,
and the card's own menu is where those live now — see the note on it below. They were a second
control for the job that menu already does, and the harder of the two to read: a button beside
a heading has to say which card it means, and with none selected it meant the group the trail
ends with rather than anything on screen. Moving a group is on that menu and never had a button
here, for the same reason and without the intervening mistake.
-->
<TextBlock Classes="label" Text="GROUPS" Foreground="{StaticResource TextDim}" />
<Border Padding="10" Background="{StaticResource DangerWash}" CornerRadius="6"
IsVisible="{Binding IsConfirmingGroupDeletion}">
@@ -259,10 +242,12 @@
</Border>
<!--
◆ MOVING THE GROUP TO ANOTHER VAULT. The host drawer's move panel, one level up and in the
place this section's buttons were. A picker and two buttons rather than a question with a yes:
what is being asked is which vault, and a move is undone by moving it back — so it is not
drawn in the danger colours the deletion question above it uses.
◆ MOVING THE GROUP TO ANOTHER VAULT. The host drawer's move panel, one level up, and under
the heading rather than in the drawer because a group has no drawer of its own. A picker and
two buttons rather than a question with a yes: what is being asked is which vault, and a move
is undone by moving it back — so it is not drawn in the danger colours the deletion question
above it uses. It sits beside that question and never with it: MoveGroup disarms a pending
deletion and DeleteGroup folds this away, so the section draws at most one of the two.
The sentence is what the panel is for. A group cannot go anywhere alone: the machines under it
are items of the vault it is leaving, and so are the groups nested inside it, so all of them
@@ -312,8 +297,8 @@
◆ THIS IS ONE LEVEL, NOT EVERY GROUP. It binds VisibleGroups: what is inside the group the
trail above ends with, or the outermost groups when it ends at ALL HOSTS. Folded away entirely
at a group with nothing inside it, which is an ordinary thing to open — the trail and the two
buttons stay, because leaving it is a gesture and editing it is a button.
at a group with nothing inside it, which is an ordinary thing to open — the trail stays, and
it is also the way back to the level where that group has a card of its own to be edited from.
◆ THESE CARDS ARE THE DROP TARGET. A host card dragged onto one is filed under that group, and
that is the whole of what a drag does on this screen. It used to be a heading inside the host
@@ -338,11 +323,11 @@
context; the code-behind selects whatever was right-clicked before the menu opens, and
cancels it outright over the space around the cards.
Open is here as well as on the double-click, and Edit and Delete as well as on the two
buttons above, and neither is a duplicate for its own sake: a gesture is unreachable without
a pointer, and the buttons act on GroupTarget — which with no card selected is the group the
trail ends with rather than the one under the pointer. This menu is the one place all three
act on the card that was right-clicked.
Open is here as well as on the double-click, which is not a duplicate for its own sake: a
gesture is unreachable without a pointer. Edit and Delete are here and nowhere else — they
were also a pair of buttons beside the heading above, which acted on GroupTarget and so with
no card selected meant the group the trail ends with rather than any card on screen. All
three act on the card that was right-clicked, which is the whole of what this menu is for.
Only Open takes a parameter, because OpenGroupCommand's null means ALL HOSTS rather than
nothing; the other three read GroupTarget, which the selection the code-behind has just made
src/DodoSSH.Client.App/Views/HostsScreen.axaml.cs
+2 -2
View File
@@ -217,8 +217,8 @@ internal sealed partial class HostsScreen : UserControl
/// The host grid's rule, applied to the cards above it — see <see cref="OnContextRequested"/>. What is
/// different is what an unaimed menu would have done: <c>GroupTarget</c> falls back to the open group
/// when no card is selected, so Edit and Delete over a card would have been offered about the group whose
/// contents are showing rather than the one the pointer is on. That fallback is right for a pair of
/// buttons that sit beside the heading and wrong for a menu that opened on a card.
/// contents are showing rather than the one the pointer is on. This menu is the only way to either of
/// them now, so aiming it is the whole of aiming them.
/// </para>
/// <para>
/// Cancelled outright over the space around the cards, as the host grid's is. That is not a group, and