/* Desktop chrome for the Tauri app.

   Every rule here is behind [data-client="desktop"], which the server puts on
   <html> when the request carries the desktop shell's User-Agent. A browser
   loads this file and nothing in it applies.

   The shell also reports its platform, because the two need different
   chrome and CSS cannot ask which OS it is on. macOS hides its titlebar and
   lets a native vibrancy layer show through the window; Windows keeps its own
   caption bar and stays opaque.

   What changes against the browser layout, and why:
     - The top bar becomes the window's titlebar. A browser tab already has
       chrome above the page; a window does not, so the row that was a web
       header is now where the traffic lights live.
     - The rail, the top bar and the sidebar stop painting a background on
       macOS so the NSVisualEffectView behind the webview comes through. The
       main pane stays opaque, which is what keeps prose readable.
     - Controls drop to Mac metrics: 13px body, 24px toolbar buttons, 28px
       rows, a real segmented control instead of underlined tabs.
     - The theme picker leaves the toolbar. It is in Settings > Profile, and a
       select in a titlebar is the most browser-shaped thing in the window.
   ========================================================================== */

:root[data-client="desktop"] {
  --topbar-h: 48px;
  --rail-w: 52px;
  --sidebar-w: 248px;
}

/* 13px is the macOS control size. The browser build sits at 14px because a
   page in a tab is read further from the eye than a window is. */
:root[data-client="desktop"] body { font-size: 13px; }

/* A window has no browser to bounce against, so rubber-banding at the end of
   a list only reveals whatever is behind the page. */
:root[data-client="desktop"] body,
:root[data-client="desktop"] .thread,
:root[data-client="desktop"] .list,
:root[data-client="desktop"] .fb-body,
:root[data-client="desktop"] .settings-content { overscroll-behavior: contain; }

/* Chrome text is not content: dragging across a toolbar in a native app
   moves the window, it does not select the label. */
:root[data-client="desktop"] .rail,
:root[data-client="desktop"] .topbar,
:root[data-client="desktop"] .tabs,
:root[data-client="desktop"] .list,
:root[data-client="desktop"] .settings-nav,
:root[data-client="desktop"] .view-actions,
:root[data-client="desktop"] .composer-controls {
  -webkit-user-select: none;
  user-select: none;
}

:root[data-client="desktop"] button,
:root[data-client="desktop"] .tab,
:root[data-client="desktop"] .settings-link,
:root[data-client="desktop"] .list-item { cursor: default; }

/* Overlay scrollbars. The 9px always-on bar reads as a web page. */
:root[data-client="desktop"] *::-webkit-scrollbar { width: 11px; height: 11px; }
:root[data-client="desktop"] *::-webkit-scrollbar-thumb {
  background: color-mix(in srgb, var(--text) 20%, transparent);
  border: 3px solid transparent;
  background-clip: content-box;
}
:root[data-client="desktop"] *::-webkit-scrollbar-thumb:hover {
  background: color-mix(in srgb, var(--text) 34%, transparent);
  background-clip: content-box;
}

/* --- the toolbar ---------------------------------------------------------- */

:root[data-client="desktop"] .ws-name { font-size: 13px; font-weight: 590; }
:root[data-client="desktop"] .topbar-left,
:root[data-client="desktop"] .topbar-right { gap: 6px; }

/* Settings > Profile owns the theme; a picker in the titlebar does not. */
:root[data-client="desktop"] #themeSelect { display: none; }

:root[data-client="desktop"] .icon-btn { width: 26px; height: 26px; }
:root[data-client="desktop"] .icon-btn svg { width: 14.5px; height: 14.5px; }

/* --- the content header, demoted ------------------------------------------ */

/* The toolbar carries the only rule across the window. What used to be a
   second bar under it becomes a page title with room around it. */
:root[data-client="desktop"] .view-head { background: transparent; border-bottom: none; }
:root[data-client="desktop"] .view-title h1 { font-size: 15px; font-weight: 590; }
:root[data-client="desktop"] .view-actions .btn {
  height: 24px;
  padding: 0 9px;
  font-size: 12px;
}

/* --- sidebar -------------------------------------------------------------- */


:root[data-client="desktop"] .list-item .name { font-size: 12.5px; }
:root[data-client="desktop"] .list-item .sub { font-size: 11.5px; }
:root[data-client="desktop"] .input.search { height: 26px; font-size: 12.5px; }

/* --- composer ------------------------------------------------------------- */

:root[data-client="desktop"] .composer-box { border-radius: var(--radius-xl); }
:root[data-client="desktop"] .composer-input { font-size: 14px; }
:root[data-client="desktop"] .ghost-select.pill { font-size: 12px; }

/* ==========================================================================
   macOS
   ========================================================================== */

/* Transparent is the normal state: the window is built with a Sidebar
   material behind the webview, and the chrome regions let it through. The
   two overrides below are the case where they must not. */
:root[data-client="desktop"][data-platform="macos"] { --desktop-chrome: transparent; }

/* The native material follows the system appearance, not the in-app theme.
   Pin the page to light on a dark system (or the reverse) and the page's own
   text colours land on the wrong material, so the chrome goes opaque and the
   window gives up its vibrancy rather than its legibility. */
@media (prefers-color-scheme: dark) {
  :root[data-client="desktop"][data-platform="macos"][data-theme="light"] {
    --desktop-chrome: var(--ground);
  }
}
@media (prefers-color-scheme: light) {
  :root[data-client="desktop"][data-platform="macos"][data-theme="dark"] {
    --desktop-chrome: var(--ground);
  }
}

:root[data-client="desktop"][data-platform="macos"] body,
:root[data-client="desktop"][data-platform="macos"] .sidebar,
:root[data-client="desktop"][data-platform="macos"] .taskbar,
:root[data-client="desktop"][data-platform="macos"] .auth-screen {
  background: var(--desktop-chrome);
}

/* The main pane never joins in. Long prose over a moving desktop is the
   reason vibrancy has a bad name. */
:root[data-client="desktop"][data-platform="macos"] .main { background: var(--surface); }

/* The rail's rule would otherwise cut straight through the traffic lights. */
:root[data-client="desktop"][data-platform="macos"] .rail { border-right: none; }

/* The toolbar is the titlebar: full width, above the rail, with the window
   controls inset into its left end. 92px clears three 12px buttons that
   start at x=19 with the system's 20px pitch; main.rs sets that origin and
   the two numbers have to move together. */
/* The window controls live in the sidebar's first row, as they do in Claude
   Code. 84px clears three 12px buttons that start at x=19 on the system's
   20px pitch; main.rs sets that origin and the two numbers move together. */
:root[data-client="desktop"][data-platform="macos"] .sidebar-top { padding-left: 84px; }
:root[data-client="desktop"][data-platform="macos"] .sidebar-top,
:root[data-client="desktop"][data-platform="macos"] .view-head,
:root[data-client="desktop"][data-platform="macos"] .taskbar-head {
  -webkit-app-region: drag;
}

/* Everything you can click has to opt out, or the drag region swallows it. */
:root[data-client="desktop"][data-platform="macos"] .sidebar-top button,
:root[data-client="desktop"][data-platform="macos"] .view-head button,
:root[data-client="desktop"][data-platform="macos"] .view-head select,
:root[data-client="desktop"][data-platform="macos"] .view-head input,
:root[data-client="desktop"][data-platform="macos"] .view-head .presence-strip,
:root[data-client="desktop"][data-platform="macos"] .taskbar-head button {
  -webkit-app-region: no-drag;
}
/* Collapsed, the sidebar's row goes with it; the header then has to clear
   the buttons on its own. */
:root[data-client="desktop"][data-platform="macos"] body.sidebar-collapsed .view-head { padding-left: 92px; }

/* Signed out there is no toolbar, so without this the window could not be
   moved at all until someone logs in. The ground around the card drags it;
   the card itself does not, or the fields inside would stop taking a click.
   Both are real elements: drag regions on pseudo-elements are unreliable
   across webviews, and this is the one screen where losing the drag leaves
   the window stuck where it opened. */
:root[data-client="desktop"][data-platform="macos"] .auth-screen {
  -webkit-app-region: drag;
}
:root[data-client="desktop"][data-platform="macos"] .auth-card,
:root[data-client="desktop"][data-platform="macos"] #inviteCard {
  -webkit-app-region: no-drag;
}

/* ==========================================================================
   Windows
   ========================================================================== */

/* The caption bar stays, so the top bar stays in the flow and nothing is
   dragged by hand. Mica sits behind the window, but WebView2 does not paint
   transparently the way WKWebView does, so every region keeps its fill. */
:root[data-client="desktop"][data-platform="windows"] .ws-name {
  font-family: "Segoe UI Variable Display", "Segoe UI", var(--font);
}

/* Separate window controls */
:root[data-client="desktop"][data-platform="macos"] .sidebar-top
{
    height: 100px;
    min-height: 100px;
    box-sizing: border-box;
    padding: 48px 16px 0;
    gap: 12px;
    flex-shrink: 0;
}

:root[data-client="desktop"][data-platform="macos"] .sidebar-top .sidebar-toggle,
:root[data-client="desktop"][data-platform="macos"] .sidebar_restore
{
    width: 36px;
    height: 36px;
    min-width: 36px;
    -webkit-app-region: no-drag;
}

:root[data-client="desktop"][data-platform="macos"] body.sidebar-collapsed .sidebar_restore
{
    top: 56px;
    left: 16px;
}

:root[data-client="desktop"][data-platform="macos"] body.sidebar-collapsed .view-head
{
    min-height: 100px;
    padding-top: 48px;
    padding-left: 64px;
    box-sizing: border-box;
}