/*
 * Teleradio branding overrides for the stock OHIF build. Injected into
 * index.html via nginx.conf's sub_filter — no image fork required.
 *
 * PREVIOUS ATTEMPT AT THIS FILE WAS A NO-OP: it overrode
 * --primary-light/--primary-main/etc. and a `.wrapper-svg-toolbar`/
 * `[data-cy='toolbar-button']` selector, none of which exist anywhere in
 * this deployed OHIF version's actual bundle (verified by decompressing
 * app.bundle.css.gz in the running container and grepping it — zero
 * matches for any of those names). That was written against older/wrong
 * OHIF docs and never actually took effect, including the blue it was
 * "using" before.
 *
 * What this OHIF build actually uses (confirmed the same way): a
 * shadcn-style HSL variable set — --primary, --secondary, --accent,
 * --muted, --background, --foreground, etc., each a raw "H S% L%" triplet
 * (no hsl() wrapper), consumed via Tailwind utilities like
 * `.bg-primary{background-color:hsl(var(--primary))}`. Defined on both
 * :root and .dark in OHIF's own bundle — overriding just :root here is
 * enough since this stylesheet loads last (linked right before </head>,
 * after OHIF's own bundle), so at equal specificity it wins over both.
 *
 * Neutral grayscale on purpose, not a blue brand color — apps/web's own
 * theme (apps/web/src/app/globals.css) is an unbranded shadcn default with
 * no real accent color; its only defined blue (--sidebar-primary) isn't
 * even wired up to anything visible. Values below are that file's actual
 * dark-mode tokens converted OKLCH -> sRGB -> HSL, so OHIF reads as the
 * same neutral palette as the rest of the app, not an invented color.
 *
 * Do a hard reload with cache disabled after any change here — OHIF's
 * hash-named bundles cache aggressively.
 */

:root {
  --background: 0 0% 4%; /* apps/web dark --background */
  --foreground: 0 0% 98%; /* apps/web dark --foreground */
  --card: 0 0% 9%; /* apps/web dark --card */
  --card-foreground: 0 0% 98%; /* apps/web dark --card-foreground */
  --popover: 0 0% 9%; /* apps/web dark --popover */
  --popover-foreground: 0 0% 98%; /* apps/web dark --popover-foreground */
  --primary: 0 0% 90%; /* apps/web dark --primary */
  --primary-foreground: 0 0% 9%; /* apps/web dark --primary-foreground */
  --secondary: 0 0% 15%; /* apps/web dark --secondary */
  --secondary-foreground: 0 0% 98%; /* apps/web dark --secondary-foreground */
  --muted: 0 0% 15%; /* apps/web dark --muted */
  --muted-foreground: 0 0% 63%; /* apps/web dark --muted-foreground */
  --accent: 0 0% 15%; /* apps/web dark --accent */
  --accent-foreground: 0 0% 98%; /* apps/web dark --accent-foreground */
  --ring: 0 0% 45%; /* apps/web dark --ring */

  /* OHIF-specific tokens with no apps/web equivalent — not part of
     shadcn's standard set, so there's nothing to convert from; mapped by
     hand to the closest neutral step above instead. --highlight in
     particular is what actually colors the viewport overlay text
     (.ViewportOverlay) and the active-tool accent — overriding --primary
     alone (as the previous version of this file assumed) has no visible
     effect on either. */
  --highlight: 0 0% 90%; /* same step as --primary */
  --neutral: 0 0% 63%; /* same step as --muted-foreground */
  --neutral-light: 0 0% 90%; /* same step as --primary */
  --neutral-dark: 0 0% 15%; /* same step as --secondary */
}

/*
 * The header bar, the "investigational use only" banner, its link/button,
 * and the toolbar/panel borders are NOT driven by any CSS custom property
 * at all — they're OHIF's own separate, hardcoded Tailwind color scale
 * (primary-dark/main/light/active, bkg-med/low, customblue-NN), compiled
 * directly into each utility class as a literal rgb() value at OHIF's own
 * build time (e.g. `.bg-primary-dark{background-color:rgb(9 12
 * 41/var(--tw-bg-opacity))}` — that 9 12 41 is fixed, not a variable
 * reference). No :root override can touch these; every :root token above
 * was confirmed against the live bundle to have zero effect on this part
 * of the UI. Found by decompressing every *.css.gz in the running
 * container and grepping for literal rgb()/hex background-color values,
 * then tracing each one back to its class name the same way.
 *
 * !important on all of these because a couple of OHIF's own hover/active
 * variants (e.g. .hover\:\!bg-primary-dark:hover) already ship with
 * !important themselves, which a plain override can't beat regardless of
 * load order.
 */
.bg-primary-dark,
.bg-bkg-med,
.hover\:bg-primary-dark:hover,
.hover\:\!bg-primary-dark:hover {
  background-color: #171717 !important; /* apps/web dark --card */
}
.border-primary-dark {
  border-color: #171717 !important;
}
.text-primary-dark {
  color: #171717 !important;
}
.bg-bkg-low {
  background-color: #0a0a0a !important; /* apps/web dark --background */
}
.bg-primary-main,
.customSelect__menu,
.customSelect__menu-list::-webkit-scrollbar-thumb,
.ohif-scrollbar::-webkit-scrollbar-thumb,
.ohif-scrollbar::-webkit-scrollbar-thumb:window-inactive {
  background-color: #262626 !important; /* apps/web dark --secondary */
}
.border-primary-main,
.customSelect__menu {
  border-color: #262626 !important;
}
.text-primary-main {
  color: #262626 !important;
}
.bg-primary-light {
  background-color: #a1a1a1 !important; /* apps/web dark --muted-foreground */
}
.border-primary-light {
  border-color: #a1a1a1 !important;
}
.text-primary-light {
  color: #a1a1a1 !important;
}
.bg-primary-active {
  background-color: #e5e5e5 !important; /* apps/web dark --primary */
}
.border-primary-active {
  border-color: #e5e5e5 !important;
}
.text-primary-active,
.text-actions-primary {
  color: #e5e5e5 !important;
}
/*
 * The "secondary" scale — confirmed directly against the live DOM (the
 * header bar's actual class is `bg-secondary-dark z-20 border-black px-1
 * relative`), not just inferred from the compiled CSS like the primary/
 * customblue rules above. Same hardcoded-hex-in-a-Tailwind-class situation
 * as those, just a scale I hadn't found yet.
 */
.bg-secondary-dark,
.active\:bg-secondary-dark:active,
.group:hover .group-hover\:bg-secondary-dark {
  background-color: #171717 !important; /* apps/web dark --card */
}
.border-secondary-main {
  border-color: #262626 !important; /* apps/web dark --secondary */
}
.hover\:bg-secondary-main:hover {
  background-color: #262626 !important;
}
.border-secondary-light,
.\!border-secondary-light,
.hover\:border-secondary-light:hover {
  border-color: #a1a1a1 !important; /* apps/web dark --muted-foreground */
}
.bg-secondary-light {
  background-color: #a1a1a1 !important;
}
.text-secondary-light {
  color: #a1a1a1 !important;
}
.stroke-secondary-light {
  stroke: #a1a1a1 !important;
}

/* Hover/active shade ramp (customblue-NN) — lower number is darker in
   OHIF's own scale, kept in the same relative order as neutral grays. */
.active\:bg-customblue-20:active {
  background-color: #262626 !important;
}
.bg-customblue-30 {
  background-color: #303030 !important;
}
.bg-customblue-40,
.active\:bg-customblue-40:active {
  background-color: #3a3a3a !important;
}
.hover\:bg-customblue-50:hover {
  background-color: #454545 !important;
}
.hover\:bg-customblue-80:hover {
  background-color: #707070 !important;
}

/* REVERTED (see conversation) — #viewerLayoutResizableLeftPanel is not just
 * a cross-patient study browser, it's also the current study's own series
 * thumbnail list (Scout/5mm Stnd/1.25mm Soft/Bone thin slice, etc.), which a
 * radiologist genuinely needs to switch reconstructions while reading.
 * Blanket-hiding it broke that. Needs a more surgical fix (hide only the
 * study-level rows, keep the series thumbnails) — not done yet.
 */

/* Larger series thumbnails. OHIF's Thumbnail component (extensions/default,
 * rendered inside #viewerLayoutResizableLeftPanel per above) hardcodes its
 * size via Tailwind arbitrary-value utility classes, not a CSS custom
 * property — confirmed by decompressing the deployed app.bundle.css.gz in
 * the running container: `.h-\[114px\]{height:114px}` and
 * `.w-\[128px\]{width:128px}` are the exact, and only, size rules. Both
 * classes are global/shared (reused by whatever else in the app happens to
 * want those exact px values), so this override is scoped to the panel
 * rather than applied bare — an unscoped `.h-\[114px\] {...}` would win via
 * source order but isn't guaranteed to stay scoped if OHIF's own CSS is
 * regenerated with a different rule order in a future image update.
 * `.w-\[128px\]` covers the image, its container, and both text-info rows
 * (they all share this one utility class), so widening it grows the whole
 * card consistently, not just the image.
 */
#viewerLayoutResizableLeftPanel .h-\[114px\] {
  height: 160px;
}
#viewerLayoutResizableLeftPanel .w-\[128px\] {
  width: 180px;
}

/*
 * Per-series/per-study loading progress bar (LoadingIndicatorProgress /
 * LoadingIndicatorTotalPercent in the bundle — OHIF already shows a numeric
 * percent natively, this is purely the track color). `.loading` is the
 * track; the moving `.infinite-loading-bar` fill has no color of its own in
 * the CSS (it's composed with one of the primary-*/secondary-* classes
 * already overridden above), so only the track needed a direct fix.
 *
 * Re-branding the loading screen's own text/logo to "Teleradio" isn't
 * possible through this file — OHIF's only documented no-fork branding hook
 * (whiteLabeling.createLogoComponentFn, used for the header logo in
 * app-config.js) doesn't cover the loading indicator, and there's no
 * equivalent hook for it. Doing that for real means writing a custom OHIF
 * extension/mode to override the component, which this repo has no build
 * tooling for yet.
 */
.loading {
  background-color: #171717 !important; /* apps/web dark --card */
}