<ResourceDictionary xmlns="https://github.com/avaloniaui"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

  <!--
    The palette, named for what a colour is for rather than for what it looks like. Every one of these is
    from the design; the names are this codebase's, because "#0E1220" appearing in nine files is how a
    surface ends up two shades off in the tenth.

    It lives here, in the shared project, because there are now two heads drawing the same product. Two
    copies of a palette is the same failure one file up: the phone's "connected" green drifting from the
    desktop's is not a thing anybody would notice until a screenshot sat beside another screenshot.

    Five near-black surfaces rather than one, and the difference between them is real work: the window is
    the darkest so the terminal reads as the lit thing, chrome sits one step up so the header and status
    bar frame it, and the lists sit between the two so a list does not look like part of either.

    ── v2 ──────────────────────────────────────────────────────────────────────────────────────────────
    This is the second design's palette: blue-black surfaces and a blue accent, replacing the green-black
    ones the first import shipped. Both heads move together, which is the whole reason the file is here —
    the Android v2 design and the desktop v2 design specify the same seventeen tokens, so a phone that went
    blue while the desktop stayed green would be the drift this file exists to prevent.

    Where the design names a colour, the value below is that colour exactly. The design has seventeen
    tokens and this palette has rather more, so the rest are interpolated along the same ramp and are
    marked. That is deliberate rather than lazy: the finer distinctions here — three border weights, four
    text steps — are ones the design draws without naming, and collapsing them to match the token count
    would lose the rule each one encodes.
  -->

  <!--
    The surfaces, darkest first. Two things changed shape rather than merely colour.

    A field is now *inset* — darker than the canvas it sits on — where it used to be raised. That follows
    the design, which draws the search box as a well rather than as a tile, and it is the one place where
    reading the old palette's ordering across to the new one gives the wrong answer.

    And Chrome and Panel are now the same value, because the design uses one surface for both the header
    and a card. They are kept as two names anyway: they answer different questions, and the day one of the
    two moves is the day having merged them would have to be undone across every file that used the wrong
    one.
  -->
  <Color x:Key="CanvasColor">#0E1220</Color>
  <SolidColorBrush x:Key="Canvas" Color="{StaticResource CanvasColor}" />
  <SolidColorBrush x:Key="Chrome" Color="#111629" />
  <SolidColorBrush x:Key="Sidebar" Color="#0F1426" />
  <SolidColorBrush x:Key="Panel" Color="#111629" />
  <SolidColorBrush x:Key="Raised" Color="#151B31" />
  <SolidColorBrush x:Key="Field" Color="#0B0F1D" />

  <!--
    The surface a terminal, a log and a snippet's command are drawn on, and it is not one of the five
    above. The design gives every block of monospaced output this one value, warmer than the chrome around
    it, and that is what makes the lit thing read as lit. Named here rather than repeated in the renderer's
    stylesheet and in two screens, which is how the three of them would drift.
  -->
  <SolidColorBrush x:Key="TerminalSurface" Color="#171A26" />

  <!-- Row hover, and the heavier one the chrome's own buttons use. On the phone these are press states. -->
  <SolidColorBrush x:Key="Hover" Color="#151B31" />
  <SolidColorBrush x:Key="ChromeHover" Color="#1D2749" />

  <!--
    Selection, and it is a surface rather than a highlight: the design fills a chosen host row, the current
    segment of a toggle and the current chip with this and adds no border. Distinct from Hover, which is
    what the finger is on rather than what is chosen.
  -->
  <SolidColorBrush x:Key="Active" Color="#1D2749" />

  <!-- The fill behind a small monospaced tag — a group name, a storage class, a bucket. -->
  <SolidColorBrush x:Key="Chip" Color="#16204A" />

  <!--
    Three border weights, and they are not interchangeable. Strong separates one region from another,
    subtle separates rows inside one region, and mid is what a control draws around itself.
  -->
  <SolidColorBrush x:Key="Border" Color="#1A2138" />
  <SolidColorBrush x:Key="BorderSubtle" Color="#151B31" />
  <SolidColorBrush x:Key="BorderMid" Color="#232B45" />
  <SolidColorBrush x:Key="BorderHover" Color="#2E3859" />
  <SolidColorBrush x:Key="BorderFaint" Color="#1F2740" />

  <!--
    The text ramp. Three steps, used consistently: what you read, what you glance at, and what is there
    only so its absence would be noticed. A fourth step would be one nobody could tell from its neighbours.

    ── The ramp is white-topped, and every step below it moved with the top. ─────────────────────────────
    The design's #E3E7F4 is a blue-tinted white, and against these blue-black surfaces the tint costs
    contrast twice: once because it is darker than white, and once because it shares a hue with what it is
    drawn on. Pure white against #0E1220 is 18.3:1, where #E3E7F4 was 15.5:1.

    Raising only the top would have been the wrong half of the change. The three steps are a ramp rather
    than three colours, and their job is that a glance can tell them apart — so lifting Text and leaving
    TextDim where it was would have widened the first gap and left the second two crowded at the bottom.
    Every step is raised by roughly what the top gained, which keeps the intervals the design chose and
    brings the lower steps up to where a secondary label is comfortably readable rather than merely
    present. TextDim clears 9:1 now, against 6.4:1 before.
  -->
  <SolidColorBrush x:Key="Text" Color="#FFFFFF" />
  <SolidColorBrush x:Key="TextDim" Color="#B4BCD4" />
  <SolidColorBrush x:Key="TextFaint" Color="#7B849F" />
  <SolidColorBrush x:Key="TextGhost" Color="#5A6280" />

  <!--
    The accent, and it is two colours rather than one. The design fills with #5B8CFF — the button, the
    floating action button, a progress bar, a toggle that is on — and writes with #8FA7FF: the current
    destination in the bottom bar, a link, the text inside a chip. They are not interchangeable in either
    direction. The fill is too saturated to read as small text on a dark surface, and the text colour is
    too pale to carry a button.

    AccentInk is what goes *on* the fill. It equals Canvas today and is named separately anyway, because
    "the darkest surface" and "the colour of text on a blue button" are two facts that happen to coincide,
    and a light theme would separate them immediately.
  -->
  <Color x:Key="AccentColor">#5B8CFF</Color>
  <SolidColorBrush x:Key="Accent" Color="{StaticResource AccentColor}" />
  <SolidColorBrush x:Key="AccentText" Color="#8FA7FF" />
  <SolidColorBrush x:Key="AccentInk" Color="#0E1220" />
  <SolidColorBrush x:Key="AccentSoft" Color="#5B8CFF" Opacity="0.35" />
  <SolidColorBrush x:Key="AccentWash" Color="#5B8CFF" Opacity="0.06" />

  <!--
    ◆ Green is no longer the accent, and that is the one semantic change in this file rather than a
    recolour.

    It used to be both: Ellipse.dot.live filled with Accent, so "a shell is open on this host" and "this is
    the thing the screen wants you to press" were the same colour by construction. The v2 design keeps a
    green — #3DDC97, for the live dot, the sync light and the follow indicator — and makes the accent blue,
    which finally separates the two. Live is that green, and nothing that is merely interactive may use it.

    Read the pair as: blue is what you can do, green is what is true.
  -->
  <SolidColorBrush x:Key="Live" Color="#3DDC97" />
  <SolidColorBrush x:Key="LiveWash" Color="#3DDC97" Opacity="0.12" />

  <!--
    The three colours that are allowed to disagree with the accent. Amber means a caveat worth reading, red
    means refused or destructive, and blue-light is for the one thing that is neither — an informational log
    line, a directory, a distinct scope.

    WarnText and DangerText are the prose weights: a wash is a very dark tint, and the signal colour that
    works as a 6-pixel dot or a one-word label is not the one that reads as a sentence on top of it. The
    design supplies both reds — #E86A6A labels the refusal and #FF8F8F writes it out — and one amber, so
    the amber prose weight is interpolated.
  -->
  <SolidColorBrush x:Key="Warn" Color="#FFB454" />
  <SolidColorBrush x:Key="WarnSoft" Color="#FFB454" Opacity="0.35" />
  <SolidColorBrush x:Key="WarnWash" Color="#FFB454" Opacity="0.12" />
  <SolidColorBrush x:Key="WarnText" Color="#E4A868" />
  <SolidColorBrush x:Key="Danger" Color="#E86A6A" />
  <SolidColorBrush x:Key="DangerSoft" Color="#E86A6A" Opacity="0.3" />
  <SolidColorBrush x:Key="DangerWash" Color="#E86A6A" Opacity="0.12" />
  <SolidColorBrush x:Key="DangerText" Color="#FF8F8F" />
  <SolidColorBrush x:Key="Info" Color="#7FB0FF" />

  <!--
    The design asks for Instrument Sans and Fira Code, as the one before it asked for IBM Plex. Neither
    ships with this application, and neither is on a stock Windows install or a stock Android one, so
    requesting them by name would render as whatever the font fallback chose that day — which is worse than
    choosing deliberately. Inter is embedded by both heads and is what they already draw with.

    The stack ends in the generic `monospace` rather than a Windows face, which is what makes it work on
    both: Android has no Cascadia Mono or Consolas and resolves the generic name to its own mono face.

    Named as a resource rather than repeated, because the substitution is the sort of thing that gets
    reversed later and should be reversible in one place. See docs/design-import-gaps.md.
  -->
  <FontFamily x:Key="MonoFont">ui-monospace,Cascadia Mono,Consolas,monospace</FontFamily>

</ResourceDictionary>
