hypr-chrome v0.1.2 #10

Merged
darman merged 19 commits from develop into master 2026-07-31 00:06:42 +02:00
Owner

Added support for gradient borders

Added support for gradient borders
darman added 18 commits 2026-07-30 00:20:43 +02:00
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reviewed-on: #1
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>
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>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Scope version-bump workflow to PRs targeting develop
Version Bump / check-bump-label (pull_request) Skipped
Version Bump / apply-version-bump (pull_request) Successful in 41s
b1bb4aecea
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reviewed-on: #2
Merge branch 'develop' into feature/gradient-border
Version Bump / check-bump-label (pull_request) Skipped
Version Bump / apply-version-bump (pull_request) Failing after 23s
48b277207f
use CI Bot token for push
Version Bump / check-bump-label (pull_request) Skipped
Version Bump / apply-version-bump (pull_request) Successful in 24s
5004064ca4
Reviewed-on: #5
Move plugin version into .env, fix version-bump workflow to only touch it
Version Bump / check-bump-label (pull_request) Skipped
Version Bump / apply-version-bump (pull_request) Successful in 23s
9acfd2b946
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>
Reviewed-on: #6
Merge branch 'develop' into feature/gradient-border
Version Bump / check-bump-label (pull_request) Skipped
Version Bump / apply-version-bump (pull_request) Successful in 23s
b328a3cb8f
Reviewed-on: #8
darman added 1 commit 2026-07-31 00:06:01 +02:00
darman added the
bump
skip
label 2026-07-31 00:06:33 +02:00
darman merged commit 26fefb35d0 into master 2026-07-31 00:06:42 +02:00
Sign in to join this conversation.