New plugin:hyprchrome:glow_size (px, 0 = off) and glow_strength (0-1)
bleed the border's own gradient inward past the window edge, over the
window's own pixels. Off by default, so existing setups are unchanged.
Drawn into the hole the ring's even-odd fill already leaves behind, from
overlapping layers - one per px of depth - each covering the window edge
inward to a progressively greater depth. Overlapping rather than abutting
disjoint bands avoids an antialiasing seam at every shared edge; the cost
is that a layer composites over every deeper one, so its alpha is solved
outermost-inward from the target profile rather than being it.
That profile is strength * (1 - d/glow)^2.2: steep off the window edge,
easing into a tail that reaches zero tangentially so there's no ring
where it stops.
Corner handling, in order of how much it mattered:
- Each layer's outer edge is the ring's inner boundary verbatim, chamfer
vertices and all. Anything else detaches the glow from the frame and
opens a sliver of unpainted window at each corner.
- Each layer's inner edge - which is what the falloff's contours actually
follow - is filleted in proportion to its own depth, so the glow reads
as chamfered where it meets the frame and rounder as it fades inward.
- Those inner edges also shrink their chamfer by (2-sqrt2) per px of
inset. Insetting a chamfered rect while holding the chamfer constant
moves the 45-degree face in by d*sqrt(2) rather than d, which had the
glow running ~41% deeper at every corner than along the sides.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The old workflow grepped CMakeLists.txt for the first "VERSION X.Y" match,
which was cmake_minimum_required's own version rather than the project's,
mangling it to 3.27.0.0 on the first real bump. PLUGIN_VERSION in .env is
now the single source of truth for both CMakeLists.txt and flake.nix, and
the workflow's bump/commit steps only ever touch that one file.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The session loads its own copy of the plugin from the Hyprland config, a
separate dlopen with its own decorations - so iterating with a dev build on
top of it drew two frames on every window.
Grep the path back out of $XDG_CONFIG_HOME/hypr rather than hardcoding it:
a home-manager-installed copy lives at a /nix/store path that changes on
every rebuild. -R, since those config files are symlinks into the store.
hyprctl plugin list reports no path, so the config is the only place to
read it from.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The frame collapsed Hyprland's border gradient to m_colors.front(), so a
gradient col.active_border showed up as a single flat color.
Snapshot the gradient (stops + angle) into a new header-only ChromeGradient
and fill the cairo path with a linear gradient built from it:
- AxisFor() reproduces the border shader's quadrant-folding progress
function (y*sin(a) + x*(1-sin(a)), not a true rotation) as a cairo axis,
so the frame's sweep stays in step with the window border it wraps.
Checked against a port of the shader across all 360 degrees: cardinal
angles exact, worst case 0.003 of the sweep (the shader folds on literal
1.57/3.14/4.71 where this uses pi).
- SampleAt() interpolates in OkLab, where the shader interpolates, with
each segment subdivided into sampled cairo stops so cairo's own sRGB lerp
tracks that curve.
active_color/inactive_color become gradient config values, taking the same
syntax as general:col.active_border. Single-color configs are unaffected.
The cross-focus fade (m_realBorderColorPrevious + fade progress, lerped
between two gradients in-shader) is still not reproduced.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
darmanandClaude Opus 5