<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.

    ── v3 ──────────────────────────────────────────────────────────────────────────────────────────────
    The third design moves again, and further in the same direction v2 moved in: v1 was green-black, v2
    blue-black, and this one near-black — the surfaces are lower-contrast against true black than either
    predecessor, and the accent turns purple, sitting where the blue used to. Both heads still move
    together for the reason given above. Where a name below still carries a v2-era comment explaining a v2
    fact in v2's numbers, that comment is a record of what v2 changed and why, not a claim about the
    current values — it is left as history except where it stated something the current palette makes
    false outright, which is called out where it happens.
  -->

  <!--
    The surfaces, darkest first. Two things changed shape rather than merely colour, in v2, and the second
    of the two has since changed back.

    A field became *inset* in v2 — darker than the canvas it sat on — where it had been raised before that.
    That followed the v2 design, which drew the search box as a well rather than as a tile. It does not
    follow this one: the v3 design gives a card and a field the same fill, rgb(16,16,25), and marks a field
    as editable with a 1.5px accent-coloured inset border instead of a darker well. Raised and Field are
    kept as separate keys anyway, for the same reason Chrome and Panel are — the day one of the two needs
    to move again, having merged them would have to be undone everywhere that used the wrong one.

    Chrome and Panel remain the same value for that reason: 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">#05050A</Color>
  <SolidColorBrush x:Key="Canvas" Color="{StaticResource CanvasColor}" />
  <SolidColorBrush x:Key="Chrome" Color="#10111E" />
  <SolidColorBrush x:Key="Sidebar" Color="#0D0D16" />
  <SolidColorBrush x:Key="Panel" Color="#10111E" />
  <SolidColorBrush x:Key="Raised" Color="#101019" />
  <SolidColorBrush x:Key="Field" Color="#101019" />

  <!--
    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.

    Not one of the design's named tokens in v3 either — the mock this palette was drawn from is a Hosts
    screen with no terminal on it — so the value is interpolated the same way it was for v2: warmer and a
    touch lighter than the new Chrome, on the same ramp as Raised and Field rather than the old blue-black
    one.
  -->
  <SolidColorBrush x:Key="TerminalSurface" Color="#18161F" />

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

  <!--
    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="#1E1E2C" />

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

  <!--
    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.

    BorderFaint changes relationship in v3: in v2 it sat above Border, lighter than it — a fact this
    comment did not previously state because nothing here described it. In this design BorderSubtle and
    BorderFaint are both a step darker than Border rather than one of them being a step lighter, so the
    weight now runs, faintest to strongest: BorderFaint, BorderSubtle, Border, BorderMid, BorderHover — a
    single ramp rather than Border sitting in the middle of two that disagree about which side it is on.
  -->
  <SolidColorBrush x:Key="Border" Color="#1E1E2C" />
  <SolidColorBrush x:Key="BorderSubtle" Color="#17172A" />
  <SolidColorBrush x:Key="BorderMid" Color="#24243A" />
  <SolidColorBrush x:Key="BorderHover" Color="#2C2C3E" />
  <SolidColorBrush x:Key="BorderFaint" Color="#141420" />

  <!--
    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. ─────────────────────────────
    This was v2's reasoning, told in v2's numbers, and is left as a record of that change rather than
    updated in place: the design's #E3E7F4 was a blue-tinted white, and against v2's blue-black surfaces
    the tint cost contrast twice — once because it was darker than white, and once because it shared a hue
    with what it was drawn on. Pure white against v2's canvas, #0E1220, was 18.6:1, where #E3E7F4 had been
    15.5:1.

    Raising only the top would have been the wrong half of that 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 was raised by roughly what the top gained, which kept the intervals the design chose and
    brought the lower steps up to where a secondary label was comfortably readable rather than merely
    present. TextDim cleared 9.8:1 at that point, against 6.4:1 before it.

    ── v3 ──────────────────────────────────────────────────────────────────────────────────────────────
    The canvas darkens again, past v2's blue-black to near-black, which raises every one of these ratios
    again without any of them moving: pure white against the new #05050A canvas is 20.3:1. TextDim,
    TextFaint and TextGhost are repicked to the design's own neutral-grey values rather than re-derived
    from v2's blue-tinted ones, because the design supplies its own steps this time — #EDEDF5, #9C9EB4 and
    #7C7F98 read against the new canvas at roughly 17.5:1, 7.7:1 and 5.2:1, in the same descending order the
    three names promise. The design also uses two deeper steps, #6D6F84 and #5D5F74, for distinctions this
    ramp does not yet draw; they are not added as keys until a screen needs them, on the same reasoning as
    the paragraph above the border ramp — a resource nothing reads is not free, because the next person to
    touch this file has to work out whether it is dead or merely not yet wired up.
  -->
  <SolidColorBrush x:Key="Text" Color="#FFFFFF" />
  <SolidColorBrush x:Key="TextDim" Color="#EDEDF5" />
  <SolidColorBrush x:Key="TextFaint" Color="#9C9EB4" />
  <SolidColorBrush x:Key="TextGhost" Color="#7C7F98" />

  <!--
    The accent, and it is two colours rather than one. The design fills with #5D42DE — the button, the
    floating action button, a progress bar, a toggle that is on — and writes with #A78BFA: 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, and it no longer equals Canvas the way it did through v1 and v2:
    the new accent is dark enough on its own that white carries better on it than the near-black the app
    otherwise writes on. "The darkest surface" and "the colour of text on the accent" were two facts that
    happened to coincide before; this design is the light theme the old comment predicted would separate
    them, arriving by a different route.

    AccentGradient and the glow beneath it are new in v3 — the design draws its primary buttons with a
    top-to-bottom gradient rather than a flat fill, lighter violet into the accent proper, and lifts them
    off the surface with a soft violet-tinted shadow rather than a border. Both are named here rather than
    inlined in App.axaml for the same reason every other accent value is: one button styled from the wrong
    purple is how a screenshot next to another screenshot finds the seam.
  -->
  <Color x:Key="AccentColor">#5D42DE</Color>
  <SolidColorBrush x:Key="Accent" Color="{StaticResource AccentColor}" />
  <SolidColorBrush x:Key="AccentText" Color="#A78BFA" />
  <SolidColorBrush x:Key="AccentInk" Color="#FFFFFF" />
  <SolidColorBrush x:Key="AccentSoft" Color="#5D42DE" Opacity="0.35" />
  <SolidColorBrush x:Key="AccentWash" Color="#5D42DE" Opacity="0.06" />
  <LinearGradientBrush x:Key="AccentGradient" StartPoint="0%,0%" EndPoint="0%,100%">
    <GradientStop Color="#8D51E7" Offset="0" />
    <GradientStop Color="#5D42DE" Offset="1" />
  </LinearGradientBrush>
  <BoxShadows x:Key="AccentGlow">0 0 22 0 #598D51E7</BoxShadows>

  <!--
    ◆ Green is still not the accent, and purple replacing blue in v3 does not reopen that question.

    Blue was the accent through v1 and v2; purple is the accent now. Either way, Ellipse.dot.live keeps its
    own colour rather than borrowing the accent's, which is the separation this comment originally recorded
    when the accent first stopped being green: "a shell is open on this host" and "this is the thing the
    screen wants you to press" read as two different colours by construction, not by coincidence of which
    two hues the current design happens to pick.

    Live is #34D399 in this design — the design's own green, a shade cooler than v2's #3DDC97 — for the
    live dot, the sync light and the follow indicator. Nothing that is merely interactive may use it.

    Read the pair as: purple is what you can do, green is what is true.
  -->
  <SolidColorBrush x:Key="Live" Color="#34D399" />
  <SolidColorBrush x:Key="LiveWash" Color="#34D399" 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.

    Info is left at its v2 value, #7FB0FF, rather than moved: it was already meant to read as distinct from
    the accent, and now that the accent has moved to purple a blue that used to sit close to it on the wheel
    sits further from it instead — the separation this colour exists for gets stronger for free.

    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. Danger
    keeps its v2 values outright — the design does not revisit red — so DangerSoft, DangerWash and
    DangerText stay derived from the same #E86A6A they always were. Warn's fill and wash move to the
    design's own #F59E0B, and WarnText to the design's own #F5B942 rather than the interpolated value v2
    carried, because this design supplies a prose weight where v2's did not name one.
  -->
  <SolidColorBrush x:Key="Warn" Color="#F59E0B" />
  <SolidColorBrush x:Key="WarnSoft" Color="#F59E0B" Opacity="0.35" />
  <SolidColorBrush x:Key="WarnWash" Color="#F59E0B" Opacity="0.12" />
  <SolidColorBrush x:Key="WarnText" Color="#F5B942" />
  <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" />

  <!--
    Montserrat, JetBrains Mono and Material Icons are embedded font files rather than names handed to the
    font fallback system, and that is a change from every design before this one. v1 asked for IBM Plex,
    v2 for Instrument Sans and Fira Code, and neither shipped with the application nor came stock on a
    Windows or an Android install, so requesting either by name would have rendered as whatever fallback
    the platform chose that day — worse than substituting deliberately. Inter stood in for both heads' sans
    and the generic `monospace` stood in for the mono stack, and that substitution was the reversible
    stand-in this comment used to describe.

    It no longer needs to be: the three faces this design names ship as TTFs under Assets/Fonts in this
    project, embedded the same way WebAssets is, and resolved by the same avares:// URI scheme Inter
    already used. MonoFont below is JetBrains Mono first, with the old system-mono stack kept after it as a
    fallback for whatever glyph JetBrains Mono does not cover. IconFont is new: the design's icons are drawn
    from Material Icons by codepoint rather than by name, and screens adopt that per glyph as they are
    touched rather than all at once — this resource only makes the face available. Program.cs makes the
    equivalent change for the sans stack, with Montserrat first and Inter kept as its fallback; see the
    remarks on BuildAvaloniaApp.
  -->
  <FontFamily x:Key="MonoFont">avares://DodoSSH.Client.Shell/Assets/Fonts#JetBrains Mono,ui-monospace,Cascadia Mono,Consolas,monospace</FontFamily>
  <FontFamily x:Key="IconFont">avares://DodoSSH.Client.Shell/Assets/Fonts#Material Icons</FontFamily>

</ResourceDictionary>