Public Access
Make the vault the thing you share, and ask a host which one it lives in
The teams screen listed teams that owned vaults, so sharing four servers with two
colleagues meant creating a team, then a vault inside it, then wrapping a key.
Two of those three steps are about a concept nobody arrives wanting. The screen
now lists vaults: naming one creates the membership list that carries it, named
after the vault and owned by you, and members, invitations, roles, hand-over and
key holders all hang off the vault they apply to.
Nothing on the server moved. VaultAccessService still resolves a shared vault
through team_membership and every membership call still names a team id — what
went is the requirement that anybody make one. The split the whole design rests
on is untouched and is still what the screen is built around: adding somebody
authorises the server to serve them, and only a machine holding the key can make
the vault readable. ADR 0009 keeps its decision and gains an addendum recording
which half of it a person is now asked about.
The one place the team resurfaces is a membership list carrying several vaults,
which this screen cannot produce and does not hide: the members section says so,
because "adding somebody here adds them there" is precisely the fact a
vault-shaped screen is in a position to conceal.
Two things left the interface and one arrived. Creating a team is gone, and so is
archiving one — it was only ever possible for a team owning no vaults, and a
screen whose rows are vaults has no row for one, so the button would have been
unreachable or always refused. The endpoint is unchanged and the screen states
the limit instead, since a vault cannot be deleted at all. The exception is a
create whose second call failed: cancelling that form archives the membership
list it left behind, which is a deliberate departure from this client's rule
against tidying up on the user's behalf, made because nothing else can reach it.
What arrived is PUT /api/v1/vaults/{id}. Without it the screen loses its only
editing action, since renaming the team behind a vault is invisible to everybody
who was never shown the team. It is gated on PermissionFlags.Admin — the line
UpdateTeamEndpoint already draws, because a name is what everybody in the vault
sees it called rather than part of its contents — and it renames the owning team
with it when that team carries nothing else, so the row an operator reads and the
name a user says cannot drift apart. The slug never moves, for the reason it does
not move on a team rename. The session edits its cached vault row rather than
replacing it with the response, which deliberately carries no wrapped key.
The host editor now asks which vault a host goes into, beside the name, while
adding and only where there is more than one vault to write to. It is a second
picker rather than the keychain screen's reused, and the two selections are
separate on purpose: that one is a standing preference about where new items go,
this is a field of the host in front of you, and binding both to one selection
would mean a click on the other screen could move a half-typed host. An existing
host is not offered it at all rather than offered it disabled — the two vaults
are encrypted under different keys, so moving an item is a delete and a retype.
That forced a fix worth naming. The group picker was built from the active
vault's groups whatever vault the host was being filed into, so a host put in a
shared vault could be filed under a group only its author can resolve — a
colleague would see it filed under nothing, which is the quietest kind of wrong.
Groups are now kept per vault and the picker follows the vault choice.
Two renames, because the pair they would otherwise have made is a bug farm:
ShellScreen.Vault became Keychain and VaultScreen became KeychainScreen, which is
what the rail has always labelled that screen, leaving Vault for one vault's
contents and Vaults for the vaults themselves. The enum values are unchanged;
NavRail.axaml writes them as x:Static literals.
1536 tests pass, seven more than before. Five are new on the server — the rename
endpoint's success, the team it does and does not take with it, the two refusals
and the empty name — and the client suite gains six and folds four together,
having lost the two about archiving a team.
This commit is contained in:
@@ -260,6 +260,28 @@
|
||||
</ComboBox.ItemTemplate>
|
||||
</ComboBox>
|
||||
|
||||
<!--
|
||||
◆ WHICH VAULT THIS HOST WILL LIVE IN. Drawn only while adding and only where there is more than
|
||||
one vault that can be written to, exactly as on the desktop — an existing host's vault cannot
|
||||
change, because the two are encrypted under different keys and moving an item is a delete and a
|
||||
retype. Above GROUP rather than below it because it decides what GROUP can offer: a group is an
|
||||
item in one vault, so choosing a vault refills that list with that vault's groups.
|
||||
-->
|
||||
<StackPanel Spacing="6" IsVisible="{Binding ShowsEditorVaultChoice}">
|
||||
<TextBlock Classes="label" Text="VAULT" Margin="0,4,0,0" />
|
||||
<ComboBox ItemsSource="{Binding EditorVaultChoices}"
|
||||
SelectedItem="{Binding EditorSelectedVault}"
|
||||
HorizontalAlignment="Stretch" MinHeight="44">
|
||||
<ComboBox.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:VaultChoiceViewModel">
|
||||
<TextBlock Classes="mono" FontSize="12" Text="{Binding Display}" />
|
||||
</DataTemplate>
|
||||
</ComboBox.ItemTemplate>
|
||||
</ComboBox>
|
||||
<TextBlock Classes="body"
|
||||
Text="A host in a shared vault is readable by everybody holding that vault's key, and it cannot be moved out afterwards." />
|
||||
</StackPanel>
|
||||
|
||||
<TextBlock Classes="label" Text="GROUP" Margin="0,4,0,0" />
|
||||
<ComboBox ItemsSource="{Binding EditorGroupChoices}"
|
||||
SelectedItem="{Binding EditorSelectedGroup}"
|
||||
|
||||
@@ -48,7 +48,7 @@
|
||||
product surface leaked the implementation's word.
|
||||
-->
|
||||
<Button Classes="row" Command="{Binding ShowScreenCommand}"
|
||||
CommandParameter="{x:Static vm:ShellScreen.Vault}">
|
||||
CommandParameter="{x:Static vm:ShellScreen.Keychain}">
|
||||
<Grid ColumnDefinitions="Auto,*,Auto">
|
||||
<TextBlock Grid.Column="0" Text="⚿" Foreground="{StaticResource AccentText}" FontSize="14"
|
||||
Width="22" VerticalAlignment="Center" />
|
||||
@@ -128,22 +128,22 @@
|
||||
</Button>
|
||||
|
||||
<!--
|
||||
Teams, which the v2 design has no row for — it is a shipped screen the design had no slot for
|
||||
Vaults, which the v2 design has no row for — it is a shipped screen the design had no slot for
|
||||
rather than a drawn one with nothing behind it. It is on the phone because an invitation is
|
||||
claimed by signing in, and somebody being invited is at least as likely to be holding a phone.
|
||||
|
||||
◎ rather than a glyph of its own. The desktop rail already draws teams with it, and two heads
|
||||
giving one destination two marks is how a user learns the wrong one.
|
||||
◎ rather than a glyph of its own. The desktop rail already draws this destination with it, and
|
||||
two heads giving one destination two marks is how a user learns the wrong one.
|
||||
-->
|
||||
<Button Classes="row" Command="{Binding ShowScreenCommand}"
|
||||
CommandParameter="{x:Static vm:ShellScreen.Team}">
|
||||
CommandParameter="{x:Static vm:ShellScreen.Vaults}">
|
||||
<Grid ColumnDefinitions="Auto,*,Auto">
|
||||
<TextBlock Grid.Column="0" Text="◎" Foreground="{StaticResource AccentText}" FontSize="14"
|
||||
Width="22" VerticalAlignment="Center" />
|
||||
<StackPanel Grid.Column="1" Spacing="2" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="Teams" />
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="Vaults" />
|
||||
<TextBlock Classes="detail" Foreground="{StaticResource TextDim}"
|
||||
Text="Who shares a keychain with you, and who holds its key." />
|
||||
Text="Your vaults, who is in each one, and who holds its key." />
|
||||
</StackPanel>
|
||||
<TextBlock Grid.Column="2" Text="›" Foreground="{StaticResource TextGhost}" FontSize="15"
|
||||
VerticalAlignment="Center" />
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
<Panel IsVisible="{Binding IsHostsShowing}">
|
||||
<views:HostsScreen DataContext="{Binding Vault}" />
|
||||
</Panel>
|
||||
<Panel IsVisible="{Binding IsVaultShowing}">
|
||||
<Panel IsVisible="{Binding IsKeychainShowing}">
|
||||
<views:KeychainScreen DataContext="{Binding Vault}" />
|
||||
</Panel>
|
||||
<!--
|
||||
@@ -153,11 +153,15 @@
|
||||
|
||||
<!--
|
||||
The sixth destination behind MORE, and the one v2 never drew — see the comment on the screen
|
||||
itself. Wrapped like its neighbours even though Teams is not nullable: the reason for the wrapper
|
||||
is the data context, not the null. IsTeamShowing is the shell's and Teams is not the shell.
|
||||
itself. Wrapped like its neighbours even though Vaults is not nullable: the reason for the
|
||||
wrapper is the data context, not the null. IsVaultsShowing is the shell's and Vaults is not the
|
||||
shell.
|
||||
|
||||
Vaults, not Vault: this one is the vaults themselves and the people in them, where the other is
|
||||
one vault's contents and is what the hosts and keychain screens draw.
|
||||
-->
|
||||
<Panel IsVisible="{Binding IsTeamShowing}">
|
||||
<views:TeamsScreen DataContext="{Binding Teams}" />
|
||||
<Panel IsVisible="{Binding IsVaultsShowing}">
|
||||
<views:VaultsScreen DataContext="{Binding Vaults}" />
|
||||
</Panel>
|
||||
|
||||
<!--
|
||||
|
||||
@@ -347,8 +347,8 @@ internal sealed partial class PhoneShell : UserControl
|
||||
switch (current.Screen)
|
||||
{
|
||||
case ShellScreen.Snippets or ShellScreen.Logs or ShellScreen.Transfers
|
||||
or ShellScreen.Buckets or ShellScreen.Preferences or ShellScreen.Team
|
||||
or ShellScreen.Vault:
|
||||
or ShellScreen.Buckets or ShellScreen.Preferences or ShellScreen.Vaults
|
||||
or ShellScreen.Keychain:
|
||||
current.ShowScreenCommand.Execute(ShellScreen.More);
|
||||
e.Handled = true;
|
||||
break;
|
||||
|
||||
@@ -1,367 +0,0 @@
|
||||
<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.TeamsScreen"
|
||||
x:DataType="vm:TeamsViewModel"
|
||||
Background="{StaticResource Canvas}">
|
||||
|
||||
<!--
|
||||
TEAMS, under MORE — and the one screen behind that hub the v2 phone design never drew.
|
||||
|
||||
It is the reverse of every other entry in docs/design-import-gaps.md: a shipped screen the design had
|
||||
no slot for, rather than a drawn screen with nothing behind it. It is on the phone because an
|
||||
invitation is claimed by *signing in*, and the person being invited is at least as likely to be
|
||||
holding a phone as sitting at a desktop — a team the server has just put somebody into, visible only
|
||||
on a head they may never have installed, is a membership they cannot see.
|
||||
|
||||
That argument is also why the invited list is drawn here and not treated as an administrator's detail:
|
||||
the people on it are the ones who cannot yet see the team, and the row says out loud that no mail was
|
||||
sent.
|
||||
|
||||
So there is no mock-up to depart from. What this departs from instead is the desktop screen over the
|
||||
same view model, and every difference below is a phone difference rather than a second opinion.
|
||||
|
||||
**The desktop's two columns are one.** A 268-pixel team list beside a members-and-vaults table does
|
||||
not exist at 360dp, so the three lists stack in one scrolling column with the teams at the top. That
|
||||
is the same thing HOSTS does with the desktop's sidebar and its connect column, and for the same
|
||||
reason.
|
||||
|
||||
**Nothing scrolls inside anything.** The desktop caps its members and vaults lists at 240 and 200
|
||||
pixels so the two can sit above each other in one pane. Here every list is sized to its content and
|
||||
the screen's own ScrollViewer does all of the scrolling: a list that scrolls inside a page is a region
|
||||
a thumb has to find the edges of, and three of them on one screen is three ways to get stuck.
|
||||
|
||||
◆ **SHARE KEY is drawn and nothing that takes something away is.** That is a decision rather than a
|
||||
subset. Wrapping a vault key is the one act on this screen a server cannot perform at all — it needs a
|
||||
machine that already holds the key, and this phone is one — so a teams screen that could only be read
|
||||
would leave the product's central claim undemonstrated on the head most people carry. REMOVE MEMBER,
|
||||
WITHDRAW KEY and REVOKE INVITATION are the other half of that, and each of them acts on the first
|
||||
press: the view model's armed-confirmation state covers archiving a team and handing one over, and
|
||||
those three are not armed by it. The desktop guards them with a tooltip instead, which is a control a
|
||||
touch screen has no way to show. An irreversible revocation under a thumb with its explanation missing
|
||||
is the wrong trade, so all three stay on the desktop — where the sentence beside them is visible.
|
||||
Archiving and hand-over are not drawn either, for a plainer reason: they decide whether a team goes on
|
||||
existing and who controls it, which is not a thing to do while walking.
|
||||
|
||||
**ADD MEMBER is not drawn either**, and it is the operation this screen least needs. It is an address
|
||||
typed into a box, a directory lookup, a role picker, and a paragraph beside it saying what adding
|
||||
somebody did *not* do — and since invitations arrived the ordinary way into a team is one the server
|
||||
claims at sign-in, which is what put this screen on the phone at all. Creating a team is here, because
|
||||
a team is where those invitations are sent from and it is two short fields.
|
||||
|
||||
**The key-holder list under a vault is not drawn.** It is a fourth list, it belongs to the selected
|
||||
vault rather than to the team, and the view model publishes no flag saying whether it has anything in
|
||||
it — so a heading for it would sit over nothing whenever nobody holds a key, which is exactly the
|
||||
empty state this head insists comes from the view model rather than from markup. What the phone can
|
||||
answer about a vault is on the vault's own row: whether *this* machine can open it.
|
||||
|
||||
**↻ and `+` both, because this screen has more reason to re-read than any other.** Nothing here is
|
||||
cached — it is all read from the server on arrival and again at the end of every command — so the one
|
||||
thing a member cannot otherwise see is a change somebody else just made: a vault key wrapped to them
|
||||
from a colleague's desktop, or a team they have this moment been invited into. On the desktop the
|
||||
re-read is leaving the rail and coming back, which is one click. Here it is a trip out to MORE and
|
||||
back, so the button earns its place. It binds to a real command rather than to ShowScreen(Team),
|
||||
which would set Screen to the value it already holds, raise nothing and reload nothing.
|
||||
-->
|
||||
|
||||
<Grid RowDefinitions="Auto,Auto,Auto,*,Auto">
|
||||
|
||||
<!-- ============ header ============ -->
|
||||
<Grid Grid.Row="0" ColumnDefinitions="Auto,*,Auto,Auto" Height="56" Margin="8,0">
|
||||
<Button Grid.Column="0" Classes="icon" Content="←"
|
||||
Command="{Binding $parent[views:PhoneShell].((vm:MainWindowViewModel)DataContext).ShowScreenCommand}"
|
||||
CommandParameter="{x:Static vm:ShellScreen.More}" />
|
||||
<TextBlock Grid.Column="1" Classes="heading" Text="Teams" Margin="4,0" />
|
||||
<Button Grid.Column="2" Classes="icon" Content="↻" Command="{Binding RefreshCommand}"
|
||||
IsEnabled="{Binding !IsBusy}" />
|
||||
<Button Grid.Column="3" Classes="icon accent" Content="+" Command="{Binding NewTeamCommand}"
|
||||
IsEnabled="{Binding !IsBusy}" />
|
||||
</Grid>
|
||||
|
||||
<!-- ============ a new team ============ -->
|
||||
<!--
|
||||
Above the list rather than in place of it, which is the opposite of what the host and snippet
|
||||
editors do — and the difference is what the form is about. Those two edit a row that is on screen,
|
||||
so a card stacked over the list hides the thing being changed. This one is about a team that does
|
||||
not exist yet, and the teams that do are exactly the useful thing to be able to see while naming it:
|
||||
the slug has to be unique on this server, and the near misses are right underneath.
|
||||
-->
|
||||
<Border Grid.Row="1" Classes="card" Margin="12,0,12,8" IsVisible="{Binding IsCreatingTeam}">
|
||||
<StackPanel Spacing="10">
|
||||
<TextBlock Classes="label" Text="NEW TEAM" />
|
||||
|
||||
<TextBox Classes="field" Text="{Binding NewTeamName}" PlaceholderText="name" />
|
||||
<TextBox Classes="field" Text="{Binding NewTeamSlug}" PlaceholderText="slug-for-urls" />
|
||||
|
||||
<TextBlock Classes="body"
|
||||
Text="The slug is lowercase letters, digits and hyphens, and has to be unique across this server. It is fixed once the team exists — a team can be renamed and its slug cannot." />
|
||||
|
||||
<Grid ColumnDefinitions="*,8,*">
|
||||
<Button Grid.Column="0" Classes="primary" Height="44" Content="CREATE"
|
||||
Command="{Binding CreateTeamCommand}" IsEnabled="{Binding !IsBusy}" />
|
||||
<Button Grid.Column="2" Classes="secondary" Height="44" Content="CANCEL"
|
||||
Command="{Binding CancelNewTeamCommand}" />
|
||||
</Grid>
|
||||
</StackPanel>
|
||||
</Border>
|
||||
|
||||
<!--
|
||||
Status, and it is the empty state as well: the view model writes "you are not in a team yet" into
|
||||
the same property it writes an offline notice and every command's outcome into. A literal here would
|
||||
be a second voice saying the same thing slightly differently.
|
||||
-->
|
||||
<TextBlock Grid.Row="2" Classes="detail" Margin="18,2,18,6" TextWrapping="Wrap"
|
||||
Text="{Binding Status}"
|
||||
IsVisible="{Binding Status, Converter={x:Static StringConverters.IsNotNullOrEmpty}}" />
|
||||
|
||||
<!-- ============ the column ============ -->
|
||||
<ScrollViewer Grid.Row="3">
|
||||
<StackPanel Margin="0,0,0,18">
|
||||
|
||||
<TextBlock Classes="section" Text="TEAMS" Margin="18,4,18,4" />
|
||||
|
||||
<!--
|
||||
Rows as cards, filled when chosen, which is what HOSTS settled on in v2 and what the radius
|
||||
ladder calls a card: one item, one rule, one thing you act on. The fill is on the item rather
|
||||
than on a Border inside it so the rounding the theme draws for selection is the row's own.
|
||||
-->
|
||||
<ListBox ItemsSource="{Binding Teams}" SelectedItem="{Binding SelectedTeam}"
|
||||
IsVisible="{Binding HasTeams}" Background="Transparent" BorderThickness="0">
|
||||
<ListBox.Styles>
|
||||
<Style Selector="ListBoxItem">
|
||||
<Setter Property="Padding" Value="0" />
|
||||
<Setter Property="MinHeight" Value="0" />
|
||||
<Setter Property="Margin" Value="10,1" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
<Style Selector="ListBoxItem:selected /template/ ContentPresenter">
|
||||
<Setter Property="Background" Value="{StaticResource Active}" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
</ListBox.Styles>
|
||||
<ListBox.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:TeamRowViewModel">
|
||||
<Grid ColumnDefinitions="*,Auto" MinHeight="54" Margin="14,11">
|
||||
<StackPanel Grid.Column="0" Spacing="3" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="{Binding Name}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
<TextBlock Classes="detail" FontSize="10.5" Text="{Binding Detail}" />
|
||||
</StackPanel>
|
||||
|
||||
<!-- The caller's own role in this team, which is what says why some of it is read-only. -->
|
||||
<Border Grid.Column="1" Classes="tag outline" Margin="8,0,0,0">
|
||||
<TextBlock Text="{Binding Role}" />
|
||||
</Border>
|
||||
</Grid>
|
||||
</DataTemplate>
|
||||
</ListBox.ItemTemplate>
|
||||
</ListBox>
|
||||
|
||||
<!-- ============ the chosen team ============ -->
|
||||
<StackPanel IsVisible="{Binding HasSelection}">
|
||||
|
||||
<TextBlock Classes="section" Text="MEMBERS" Margin="18,18,18,4" />
|
||||
|
||||
<ListBox ItemsSource="{Binding Members}" SelectedItem="{Binding SelectedMember}"
|
||||
Background="Transparent" BorderThickness="0">
|
||||
<ListBox.Styles>
|
||||
<Style Selector="ListBoxItem">
|
||||
<Setter Property="Padding" Value="0" />
|
||||
<Setter Property="MinHeight" Value="0" />
|
||||
<Setter Property="Margin" Value="10,1" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
<Style Selector="ListBoxItem:selected /template/ ContentPresenter">
|
||||
<Setter Property="Background" Value="{StaticResource Active}" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
</ListBox.Styles>
|
||||
<ListBox.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:TeamMemberRowViewModel">
|
||||
<Grid ColumnDefinitions="*,Auto" MinHeight="54" Margin="14,11">
|
||||
<StackPanel Grid.Column="0" Spacing="3" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="{Binding Name}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
<TextBlock Classes="detail" FontSize="10.5" Text="{Binding Email}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
|
||||
<!--
|
||||
◆ The one fact on this row that decides whether the button at the foot of the screen
|
||||
can do anything: an account with no published identity key has nothing for a vault
|
||||
key to be wrapped to. One sentence, from the view model, painted twice rather than
|
||||
written twice — the warning colour is the whole of the difference, and a converter
|
||||
for it would hide that the two are the same string.
|
||||
|
||||
The published case is quiet rather than green. Green on this head means a shell is
|
||||
open right now, and a published key is a durable fact about an account — borrowing
|
||||
the status colour for it would be the second meaning that makes the first
|
||||
unreadable. Only the missing key is coloured, because only it needs answering.
|
||||
-->
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource TextDim}" Text="{Binding KeyState}"
|
||||
IsVisible="{Binding Member.IsEnrolled}" />
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource WarnText}" Text="{Binding KeyState}"
|
||||
IsVisible="{Binding !Member.IsEnrolled}" />
|
||||
|
||||
<!--
|
||||
A date to the day, or that they have never been here at all. The view model writes
|
||||
both, and neither is a guess: the server records the account's last authenticated
|
||||
request at most once an hour, which is what makes a day the honest unit.
|
||||
-->
|
||||
<TextBlock Classes="detail" FontSize="9.5" Foreground="{StaticResource TextFaint}"
|
||||
Text="{Binding LastActive}" />
|
||||
</StackPanel>
|
||||
|
||||
<Border Grid.Column="1" Classes="tag outline" Margin="8,0,0,0">
|
||||
<TextBlock Text="{Binding Role}" />
|
||||
</Border>
|
||||
</Grid>
|
||||
</DataTemplate>
|
||||
</ListBox.ItemTemplate>
|
||||
</ListBox>
|
||||
|
||||
<TextBlock Classes="body" Margin="18,10,18,0"
|
||||
Text="Being in a team is what lets the server hand somebody this team's vaults. It is not what lets them read one: a vault key can only be wrapped by a machine that already holds it, which is what sharing below does." />
|
||||
|
||||
<!-- ============ ◆ who has been asked and has not arrived ============ -->
|
||||
<!--
|
||||
The section this screen exists for, and the one the desktop had nothing to draw until
|
||||
invitations were built. Read-only here: withdrawing one is a control that acts on the first
|
||||
press, which is the line drawn at the top of this file.
|
||||
|
||||
So these are cards rather than the flat rows above them, and the shape is the difference: a row
|
||||
that fills when you touch it is one of several you are choosing between, and there is nothing
|
||||
to choose here. An ItemsControl rather than a ListBox for the same reason — a list with a
|
||||
selection nothing reads would be a control offering something it cannot do.
|
||||
|
||||
Gated on the view model's own count rather than left to stand over an empty list, because a
|
||||
team with nobody outstanding is the ordinary case and a permanent empty heading would make it
|
||||
look like a section that had failed to load.
|
||||
|
||||
The waiting row carries the whole mechanism in its own sentence — no mail was sent, and they
|
||||
join when they first sign in here. That is the sentence somebody has to read, because every
|
||||
other product's version of this word means an email is on its way.
|
||||
-->
|
||||
<StackPanel IsVisible="{Binding HasInvitations}">
|
||||
<TextBlock Classes="section" Text="INVITED" Margin="18,18,18,4" />
|
||||
|
||||
<ItemsControl ItemsSource="{Binding Invitations}">
|
||||
<ItemsControl.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:TeamInvitationRowViewModel">
|
||||
<Border Classes="card" Margin="12,3">
|
||||
<Grid ColumnDefinitions="*,Auto">
|
||||
<StackPanel Grid.Column="0" Spacing="3" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="12.5" Text="{Binding Email}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource TextDim}" Text="{Binding State}"
|
||||
IsVisible="{Binding !IsPending}" />
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource WarnText}" Text="{Binding State}"
|
||||
IsVisible="{Binding IsPending}" />
|
||||
</StackPanel>
|
||||
<Border Grid.Column="1" Classes="tag outline" Margin="8,0,0,0">
|
||||
<TextBlock Text="{Binding Role}" />
|
||||
</Border>
|
||||
</Grid>
|
||||
</Border>
|
||||
</DataTemplate>
|
||||
</ItemsControl.ItemTemplate>
|
||||
</ItemsControl>
|
||||
</StackPanel>
|
||||
|
||||
<TextBlock Classes="section" Text="VAULTS" Margin="18,18,18,4" />
|
||||
|
||||
<ListBox ItemsSource="{Binding Vaults}" SelectedItem="{Binding SelectedVault}"
|
||||
Background="Transparent" BorderThickness="0">
|
||||
<ListBox.Styles>
|
||||
<Style Selector="ListBoxItem">
|
||||
<Setter Property="Padding" Value="0" />
|
||||
<Setter Property="MinHeight" Value="0" />
|
||||
<Setter Property="Margin" Value="10,1" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
<Style Selector="ListBoxItem:selected /template/ ContentPresenter">
|
||||
<Setter Property="Background" Value="{StaticResource Active}" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
</ListBox.Styles>
|
||||
<ListBox.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:TeamVaultRowViewModel">
|
||||
<StackPanel Spacing="3" MinHeight="54" Margin="14,11" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="{Binding Name}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
|
||||
<!--
|
||||
Whether *this* phone can open it, which is a property of its keyring rather than
|
||||
anything the server could answer. Painted the same two ways as the member's key
|
||||
state above, because it is the same question asked from the other end.
|
||||
-->
|
||||
<TextBlock Classes="detail" FontSize="10.5" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource TextDim}" Text="{Binding State}"
|
||||
IsVisible="{Binding IsReadable}" />
|
||||
<TextBlock Classes="detail" FontSize="10.5" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource WarnText}" Text="{Binding State}"
|
||||
IsVisible="{Binding !IsReadable}" />
|
||||
</StackPanel>
|
||||
</DataTemplate>
|
||||
</ListBox.ItemTemplate>
|
||||
</ListBox>
|
||||
|
||||
<TextBlock Classes="body" Margin="18,10,18,0"
|
||||
Text="A vault listed here that this phone has no key to stays listed and stays shut. That is the ordinary case rather than a fault: somebody has been added to the team and nobody has wrapped the key to them yet." />
|
||||
|
||||
</StackPanel>
|
||||
|
||||
</StackPanel>
|
||||
</ScrollViewer>
|
||||
|
||||
<!-- ============ ◆ giving somebody the key ============ -->
|
||||
<!--
|
||||
Raised over the column when both halves of the act have been chosen, as HOSTS raises its connect bar
|
||||
and SNIPPETS its insert bar, and for the reason written there: there is no second column to put it
|
||||
in, so it names what it will do rather than relying on a selection being visible beside the button.
|
||||
|
||||
Two wrappers rather than one condition. Sharing needs a member *and* a vault, and a binding cannot
|
||||
say `SelectedMember is not null && SelectedVault is not null` without a converter that does not
|
||||
exist — the log screen makes the same trade for the same reason. It also gets the halves in the
|
||||
right order: choosing who comes first, and until a vault is chosen there is nothing to offer them.
|
||||
-->
|
||||
<Panel Grid.Row="4" IsVisible="{Binding SelectedMember, Converter={x:Static ObjectConverters.IsNotNull}}">
|
||||
<Border IsVisible="{Binding SelectedVault, Converter={x:Static ObjectConverters.IsNotNull}}"
|
||||
Background="{StaticResource Chrome}" BorderBrush="{StaticResource Border}"
|
||||
BorderThickness="0,1,0,0" Padding="14,12">
|
||||
<StackPanel Spacing="9">
|
||||
|
||||
<StackPanel Orientation="Horizontal" Spacing="8">
|
||||
<TextBlock Classes="label" Text="THE KEY TO" />
|
||||
<TextBlock Classes="mono" FontSize="11" Text="{Binding SelectedVault.Name}"
|
||||
TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
|
||||
</StackPanel>
|
||||
|
||||
<StackPanel Orientation="Horizontal" Spacing="8">
|
||||
<TextBlock Classes="label" Text="FOR" />
|
||||
<TextBlock Classes="mono" FontSize="11" Text="{Binding SelectedMember.Name}"
|
||||
TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
|
||||
</StackPanel>
|
||||
|
||||
<Button Classes="primary" Content="SHARE KEY" Command="{Binding ShareVaultCommand}"
|
||||
IsEnabled="{Binding !IsBusy}" />
|
||||
|
||||
<!--
|
||||
The sentence the desktop hangs off a tooltip, which a phone cannot show — so it is body text
|
||||
under the button, where it is read before the tap rather than after it. It is not decoration:
|
||||
the key-log check proves this server has been consistent with itself and nothing more.
|
||||
-->
|
||||
<TextBlock Classes="body"
|
||||
Text="Their published key is checked against the server's append-only key log first, and nothing is wrapped if it does not appear there unchanged. That proves the server has been consistent with itself — not that the key is the right person's. Compare the fingerprint with them over a channel this server does not carry before sharing anything that matters." />
|
||||
|
||||
</StackPanel>
|
||||
</Border>
|
||||
</Panel>
|
||||
|
||||
</Grid>
|
||||
|
||||
</UserControl>
|
||||
@@ -1,10 +0,0 @@
|
||||
using Avalonia.Controls;
|
||||
using Avalonia.Markup.Xaml;
|
||||
|
||||
namespace DodoSSH.Client.Android.Views;
|
||||
|
||||
/// <summary>Teams, under MORE — who is in one, and which of its vaults this phone can open.</summary>
|
||||
internal sealed partial class TeamsScreen : UserControl
|
||||
{
|
||||
public TeamsScreen() => AvaloniaXamlLoader.Load(this);
|
||||
}
|
||||
@@ -0,0 +1,347 @@
|
||||
<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.VaultsScreen"
|
||||
x:DataType="vm:VaultsViewModel"
|
||||
Background="{StaticResource Canvas}">
|
||||
|
||||
<!--
|
||||
VAULTS, under MORE — and the one screen behind that hub the v2 phone design never drew.
|
||||
|
||||
It is the reverse of every other entry in docs/design-import-gaps.md: a shipped screen the design had
|
||||
no slot for, rather than a drawn screen with nothing behind it. It is on the phone because an
|
||||
invitation is claimed by *signing in*, and the person being invited is at least as likely to be
|
||||
holding a phone as sitting at a desktop — a vault the server has just put somebody into, visible only
|
||||
on a head they may never have installed, is a membership they cannot see.
|
||||
|
||||
That argument is also why the invited list is drawn here and not treated as an administrator's detail:
|
||||
the people on it are the ones who cannot yet see the vault, and the row says out loud that no mail was
|
||||
sent.
|
||||
|
||||
── IT LISTED TEAMS UNTIL THE SCREEN STOPPED BEING ABOUT THEM. ───────────────────────────────────────
|
||||
The rows are vaults now, and the members under one are the people that vault is shared with. Nothing
|
||||
about the server changed — it still authorises through a team — and what went is the step where
|
||||
somebody had to make one before they could share anything. See VaultsViewModel.
|
||||
|
||||
So there is no mock-up to depart from. What this departs from instead is the desktop screen over the
|
||||
same view model, and every difference below is a phone difference rather than a second opinion.
|
||||
|
||||
**The desktop's two columns are one.** A 268-pixel vault list beside a members table does not exist at
|
||||
360dp, so the lists stack in one scrolling column with the vaults at the top. That is the same thing
|
||||
HOSTS does with the desktop's sidebar and its connect column, and for the same reason.
|
||||
|
||||
**Nothing scrolls inside anything.** The desktop caps its members list at 240 pixels so several can sit
|
||||
above each other in one pane. Here every list is sized to its content and the screen's own ScrollViewer
|
||||
does all of the scrolling: a list that scrolls inside a page is a region a thumb has to find the edges
|
||||
of, and three of them on one screen is three ways to get stuck.
|
||||
|
||||
◆ **SHARE KEY is drawn and nothing that takes something away is.** That is a decision rather than a
|
||||
subset. Wrapping a vault key is the one act on this screen a server cannot perform at all — it needs a
|
||||
machine that already holds the key, and this phone is one — so a vaults screen that could only be read
|
||||
would leave the product's central claim undemonstrated on the head most people carry. REMOVE, WITHDRAW
|
||||
KEY and WITHDRAW INVITATION are the other half of that, and each of them acts on the first press: the
|
||||
view model's armed-confirmation state covers handing a vault over and nothing else. The desktop guards
|
||||
them with a tooltip instead, which is a control a touch screen has no way to show. An irreversible
|
||||
revocation under a thumb with its explanation missing is the wrong trade, so all three stay on the
|
||||
desktop — where the sentence beside them is visible. Handing a vault over is not drawn either, for a
|
||||
plainer reason: it decides who controls the vault, which is not a thing to do while walking. Nor is
|
||||
renaming, which is a keyboard on a screen that is otherwise all reading.
|
||||
|
||||
**ADD is not drawn either**, and it is the operation this screen least needs. It is an address typed
|
||||
into a box, a directory lookup, a role picker, and a paragraph beside it saying what adding somebody
|
||||
did *not* do — and since invitations arrived the ordinary way into a vault is one the server claims at
|
||||
sign-in, which is what put this screen on the phone at all. Making a vault is here, because it is one
|
||||
field and because it is what a person carrying a phone can usefully start.
|
||||
|
||||
**The key-holder list is not drawn.** It is a third list, and what the phone can answer about a vault
|
||||
is the more useful half of the same question and is on the vault's own row: whether *this* machine can
|
||||
open it.
|
||||
|
||||
**↻ and `+` both, because this screen has more reason to re-read than any other.** Who is in a vault is
|
||||
not cached — it is read from the server on arrival and again at the end of every command — so the one
|
||||
thing a member cannot otherwise see is a change somebody else just made: a vault key wrapped to them
|
||||
from a colleague's desktop, or a vault they have this moment been invited into. On the desktop the
|
||||
re-read is leaving the rail and coming back, which is one click. Here it is a trip out to MORE and
|
||||
back, so the button earns its place. It binds to a real command rather than to ShowScreen(Vaults),
|
||||
which would set Screen to the value it already holds, raise nothing and reload nothing.
|
||||
-->
|
||||
|
||||
<Grid RowDefinitions="Auto,Auto,Auto,*,Auto">
|
||||
|
||||
<!-- ============ header ============ -->
|
||||
<Grid Grid.Row="0" ColumnDefinitions="Auto,*,Auto,Auto" Height="56" Margin="8,0">
|
||||
<Button Grid.Column="0" Classes="icon" Content="←"
|
||||
Command="{Binding $parent[views:PhoneShell].((vm:MainWindowViewModel)DataContext).ShowScreenCommand}"
|
||||
CommandParameter="{x:Static vm:ShellScreen.More}" />
|
||||
<TextBlock Grid.Column="1" Classes="heading" Text="Vaults" Margin="4,0" />
|
||||
<Button Grid.Column="2" Classes="icon" Content="↻" Command="{Binding RefreshCommand}"
|
||||
IsEnabled="{Binding !IsBusy}" />
|
||||
<Button Grid.Column="3" Classes="icon accent" Content="+" Command="{Binding NewVaultCommand}"
|
||||
IsEnabled="{Binding !IsBusy}" />
|
||||
</Grid>
|
||||
|
||||
<!-- ============ a new vault ============ -->
|
||||
<!--
|
||||
Above the list rather than in place of it, which is the opposite of what the host and snippet
|
||||
editors do — and the difference is what the form is about. Those two edit a row that is on screen,
|
||||
so a card stacked over the list hides the thing being changed. This one is about a vault that does
|
||||
not exist yet, and the vaults that do are exactly the useful thing to be able to see while naming it.
|
||||
-->
|
||||
<Border Grid.Row="1" Classes="card" Margin="12,0,12,8" IsVisible="{Binding IsCreatingVault}">
|
||||
<StackPanel Spacing="10">
|
||||
<TextBlock Classes="label" Text="NEW VAULT" />
|
||||
|
||||
<TextBox Classes="field" Text="{Binding NewVaultName}" PlaceholderText="name" />
|
||||
|
||||
<TextBlock Classes="body"
|
||||
Text="Its key is made on this phone and nobody else has it. Add people to it once it exists, then share the key with them." />
|
||||
|
||||
<Grid ColumnDefinitions="*,8,*">
|
||||
<Button Grid.Column="0" Classes="primary" Height="44" Content="CREATE"
|
||||
Command="{Binding CreateVaultCommand}" IsEnabled="{Binding !IsBusy}" />
|
||||
<Button Grid.Column="2" Classes="secondary" Height="44" Content="CANCEL"
|
||||
Command="{Binding CancelNewVaultCommand}" />
|
||||
</Grid>
|
||||
</StackPanel>
|
||||
</Border>
|
||||
|
||||
<!--
|
||||
Status, and it is the empty state as well: the view model writes "locked" and every command's
|
||||
outcome into the same property. A literal here would be a second voice saying the same thing
|
||||
slightly differently.
|
||||
-->
|
||||
<TextBlock Grid.Row="2" Classes="detail" Margin="18,2,18,6" TextWrapping="Wrap"
|
||||
Text="{Binding Status}"
|
||||
IsVisible="{Binding Status, Converter={x:Static StringConverters.IsNotNullOrEmpty}}" />
|
||||
|
||||
<!-- ============ the column ============ -->
|
||||
<ScrollViewer Grid.Row="3">
|
||||
<StackPanel Margin="0,0,0,18">
|
||||
|
||||
<TextBlock Classes="section" Text="VAULTS" Margin="18,4,18,4" />
|
||||
|
||||
<!--
|
||||
Rows as cards, filled when chosen, which is what HOSTS settled on in v2 and what the radius
|
||||
ladder calls a card: one item, one rule, one thing you act on. The fill is on the item rather
|
||||
than on a Border inside it so the rounding the theme draws for selection is the row's own.
|
||||
-->
|
||||
<ListBox ItemsSource="{Binding Vaults}" SelectedItem="{Binding SelectedVault}"
|
||||
IsVisible="{Binding HasVaults}" Background="Transparent" BorderThickness="0">
|
||||
<ListBox.Styles>
|
||||
<Style Selector="ListBoxItem">
|
||||
<Setter Property="Padding" Value="0" />
|
||||
<Setter Property="MinHeight" Value="0" />
|
||||
<Setter Property="Margin" Value="10,1" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
<Style Selector="ListBoxItem:selected /template/ ContentPresenter">
|
||||
<Setter Property="Background" Value="{StaticResource Active}" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
</ListBox.Styles>
|
||||
<ListBox.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:VaultRowViewModel">
|
||||
<Grid ColumnDefinitions="*,Auto" MinHeight="54" Margin="14,11">
|
||||
<StackPanel Grid.Column="0" Spacing="3" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="{Binding Name}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
<TextBlock Classes="detail" FontSize="10.5" Text="{Binding Detail}" />
|
||||
|
||||
<!--
|
||||
Whether *this* phone can open it, and whether a rekey is owed. Coloured because both
|
||||
states need somebody to act; drawn at all only when there is one, so an ordinary vault
|
||||
carries no line rather than a reassurance nobody reads.
|
||||
-->
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource WarnText}" Text="{Binding State}"
|
||||
IsVisible="{Binding HasState}" />
|
||||
</StackPanel>
|
||||
|
||||
<!-- The caller's own role here, which is what says why some of it is read-only. -->
|
||||
<Border Grid.Column="1" Classes="tag outline" Margin="8,0,0,0">
|
||||
<TextBlock Text="{Binding RoleLabel}" />
|
||||
</Border>
|
||||
</Grid>
|
||||
</DataTemplate>
|
||||
</ListBox.ItemTemplate>
|
||||
</ListBox>
|
||||
|
||||
<!-- ============ the chosen vault ============ -->
|
||||
<StackPanel IsVisible="{Binding HasSelection}">
|
||||
|
||||
<!--
|
||||
The personal vault has no members and never will, so the members heading is gated on the vault
|
||||
being one that can have them rather than left standing over an empty list.
|
||||
-->
|
||||
<TextBlock Classes="body" Margin="18,18,18,0" IsVisible="{Binding SelectedIsPersonal}"
|
||||
Text="Nobody can be added to your personal vault, and the server refuses a key grant on one outright. Make a vault for the things you want to share, and put them in it." />
|
||||
|
||||
<StackPanel IsVisible="{Binding SelectedIsShared}">
|
||||
|
||||
<TextBlock Classes="section" Text="MEMBERS" Margin="18,18,18,4" />
|
||||
|
||||
<TextBlock Classes="body" Margin="18,0,18,4" IsVisible="{Binding HasSharedMembershipWarning}"
|
||||
Text="{Binding SharedMembershipWarning}" />
|
||||
|
||||
<ListBox ItemsSource="{Binding Members}" SelectedItem="{Binding SelectedMember}"
|
||||
Background="Transparent" BorderThickness="0">
|
||||
<ListBox.Styles>
|
||||
<Style Selector="ListBoxItem">
|
||||
<Setter Property="Padding" Value="0" />
|
||||
<Setter Property="MinHeight" Value="0" />
|
||||
<Setter Property="Margin" Value="10,1" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
<Style Selector="ListBoxItem:selected /template/ ContentPresenter">
|
||||
<Setter Property="Background" Value="{StaticResource Active}" />
|
||||
<Setter Property="CornerRadius" Value="12" />
|
||||
</Style>
|
||||
</ListBox.Styles>
|
||||
<ListBox.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:VaultMemberRowViewModel">
|
||||
<Grid ColumnDefinitions="*,Auto" MinHeight="54" Margin="14,11">
|
||||
<StackPanel Grid.Column="0" Spacing="3" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="13.5" FontWeight="SemiBold" Text="{Binding Name}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
<TextBlock Classes="detail" FontSize="10.5" Text="{Binding Email}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
|
||||
<!--
|
||||
◆ The one fact on this row that decides whether the button at the foot of the screen
|
||||
can do anything: an account with no published identity key has nothing for a vault
|
||||
key to be wrapped to. One sentence, from the view model, painted twice rather than
|
||||
written twice — the warning colour is the whole of the difference, and a converter
|
||||
for it would hide that the two are the same string.
|
||||
|
||||
The published case is quiet rather than green. Green on this head means a shell is
|
||||
open right now, and a published key is a durable fact about an account — borrowing
|
||||
the status colour for it would be the second meaning that makes the first
|
||||
unreadable. Only the missing key is coloured, because only it needs answering.
|
||||
-->
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource TextDim}" Text="{Binding KeyState}"
|
||||
IsVisible="{Binding Member.IsEnrolled}" />
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource WarnText}" Text="{Binding KeyState}"
|
||||
IsVisible="{Binding !Member.IsEnrolled}" />
|
||||
|
||||
<!--
|
||||
A date to the day, or that they have never been here at all. The view model writes
|
||||
both, and neither is a guess: the server records the account's last authenticated
|
||||
request at most once an hour, which is what makes a day the honest unit.
|
||||
-->
|
||||
<TextBlock Classes="detail" FontSize="9.5" Foreground="{StaticResource TextFaint}"
|
||||
Text="{Binding LastActive}" />
|
||||
</StackPanel>
|
||||
|
||||
<Border Grid.Column="1" Classes="tag outline" Margin="8,0,0,0">
|
||||
<TextBlock Text="{Binding Role}" />
|
||||
</Border>
|
||||
</Grid>
|
||||
</DataTemplate>
|
||||
</ListBox.ItemTemplate>
|
||||
</ListBox>
|
||||
|
||||
<TextBlock Classes="body" Margin="18,10,18,0"
|
||||
Text="Being in a vault is what lets the server hand somebody its rows. It is not what lets them read one: a vault key can only be wrapped by a machine that already holds it, which is what sharing below does." />
|
||||
|
||||
<!-- ============ ◆ who has been asked and has not arrived ============ -->
|
||||
<!--
|
||||
The section this screen exists for, and the one the desktop had nothing to draw until
|
||||
invitations were built. Read-only here: withdrawing one is a control that acts on the first
|
||||
press, which is the line drawn at the top of this file.
|
||||
|
||||
So these are cards rather than the flat rows above them, and the shape is the difference: a
|
||||
row that fills when you touch it is one of several you are choosing between, and there is
|
||||
nothing to choose here. An ItemsControl rather than a ListBox for the same reason — a list
|
||||
with a selection nothing reads would be a control offering something it cannot do.
|
||||
|
||||
Gated on the view model's own count rather than left to stand over an empty list, because a
|
||||
vault with nobody outstanding is the ordinary case and a permanent empty heading would make
|
||||
it look like a section that had failed to load.
|
||||
|
||||
The waiting row carries the whole mechanism in its own sentence — no mail was sent, and they
|
||||
join when they first sign in here. That is the sentence somebody has to read, because every
|
||||
other product's version of this word means an email is on its way.
|
||||
-->
|
||||
<StackPanel IsVisible="{Binding HasInvitations}">
|
||||
<TextBlock Classes="section" Text="INVITED" Margin="18,18,18,4" />
|
||||
|
||||
<ItemsControl ItemsSource="{Binding Invitations}">
|
||||
<ItemsControl.ItemTemplate>
|
||||
<DataTemplate x:DataType="vm:VaultInvitationRowViewModel">
|
||||
<Border Classes="card" Margin="12,3">
|
||||
<Grid ColumnDefinitions="*,Auto">
|
||||
<StackPanel Grid.Column="0" Spacing="3" VerticalAlignment="Center">
|
||||
<TextBlock Classes="mono" FontSize="12.5" Text="{Binding Email}"
|
||||
TextTrimming="CharacterEllipsis" />
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource TextDim}" Text="{Binding State}"
|
||||
IsVisible="{Binding !IsPending}" />
|
||||
<TextBlock Classes="detail" FontSize="10" TextWrapping="Wrap"
|
||||
Foreground="{StaticResource WarnText}" Text="{Binding State}"
|
||||
IsVisible="{Binding IsPending}" />
|
||||
</StackPanel>
|
||||
<Border Grid.Column="1" Classes="tag outline" Margin="8,0,0,0">
|
||||
<TextBlock Text="{Binding Role}" />
|
||||
</Border>
|
||||
</Grid>
|
||||
</Border>
|
||||
</DataTemplate>
|
||||
</ItemsControl.ItemTemplate>
|
||||
</ItemsControl>
|
||||
</StackPanel>
|
||||
|
||||
</StackPanel>
|
||||
|
||||
</StackPanel>
|
||||
|
||||
</StackPanel>
|
||||
</ScrollViewer>
|
||||
|
||||
<!-- ============ ◆ giving somebody the key ============ -->
|
||||
<!--
|
||||
Raised over the column when somebody has been chosen, as HOSTS raises its connect bar and SNIPPETS
|
||||
its insert bar, and for the reason written there: there is no second column to put it in, so it names
|
||||
what it will do rather than relying on a selection being visible beside the button.
|
||||
|
||||
One condition where there used to be two. Sharing needs a member and a vault, and the vault is now
|
||||
the thing the whole screen is about — a member can only be selected under one, so choosing who is the
|
||||
only half left to make.
|
||||
-->
|
||||
<Border Grid.Row="4"
|
||||
IsVisible="{Binding SelectedMember, Converter={x:Static ObjectConverters.IsNotNull}}"
|
||||
Background="{StaticResource Chrome}" BorderBrush="{StaticResource Border}"
|
||||
BorderThickness="0,1,0,0" Padding="14,12">
|
||||
<StackPanel Spacing="9">
|
||||
|
||||
<StackPanel Orientation="Horizontal" Spacing="8">
|
||||
<TextBlock Classes="label" Text="THE KEY TO" />
|
||||
<TextBlock Classes="mono" FontSize="11" Text="{Binding SelectedVault.Name}"
|
||||
TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
|
||||
</StackPanel>
|
||||
|
||||
<StackPanel Orientation="Horizontal" Spacing="8">
|
||||
<TextBlock Classes="label" Text="FOR" />
|
||||
<TextBlock Classes="mono" FontSize="11" Text="{Binding SelectedMember.Name}"
|
||||
TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
|
||||
</StackPanel>
|
||||
|
||||
<Button Classes="primary" Content="SHARE KEY" Command="{Binding ShareVaultCommand}"
|
||||
IsEnabled="{Binding !IsBusy}" />
|
||||
|
||||
<!--
|
||||
The sentence the desktop hangs off a tooltip, which a phone cannot show — so it is body text
|
||||
under the button, where it is read before the tap rather than after it. It is not decoration:
|
||||
the key-log check proves this server has been consistent with itself and nothing more.
|
||||
-->
|
||||
<TextBlock Classes="body"
|
||||
Text="Their published key is checked against the server's append-only key log first, and nothing is wrapped if it does not appear there unchanged. That proves the server has been consistent with itself — not that the key is the right person's. Compare the fingerprint with them over a channel this server does not carry before sharing anything that matters." />
|
||||
|
||||
</StackPanel>
|
||||
</Border>
|
||||
|
||||
</Grid>
|
||||
|
||||
</UserControl>
|
||||
@@ -0,0 +1,10 @@
|
||||
using Avalonia.Controls;
|
||||
using Avalonia.Markup.Xaml;
|
||||
|
||||
namespace DodoSSH.Client.Android.Views;
|
||||
|
||||
/// <summary>Vaults, under MORE — who is in each, and which of them this phone can open.</summary>
|
||||
internal sealed partial class VaultsScreen : UserControl
|
||||
{
|
||||
public VaultsScreen() => AvaloniaXamlLoader.Load(this);
|
||||
}
|
||||
Reference in New Issue
Block a user