6 Commits

Include renames

Author	SHA1	Message	Date
darmanandClaude Opus 5	1735a5c796	Add an inward glow bleeding from the border over the window ... 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>	2026-07-31 01:19:16 +02:00
darmanandClaude Opus 5	375cfe1f00	Unload the config-installed plugin copy in buildAndLoad.sh ... 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>	2026-07-29 20:36:41 +02:00
darmanandClaude Opus 5	b9dafe2ce1	Render border gradients instead of a flat first stop ... 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>	2026-07-29 20:36:24 +02:00
darmanandClaude Sonnet 5	48a56b31f6	Document develop/master branching model in CLAUDE.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 21:32:55 +02:00
darmanandClaude Sonnet 5	6d9d1bcd82	Require feature/fix branches instead of direct master commits ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 21:27:32 +02:00
darman	a28a899874	hypr-chrome v0.1	2026-07-28 21:22:13 +02:00