darmanandClaude Opus 5
1735a5c796
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>
hypr-chrome
A Hyprland plugin that draws a chamfered HUD-style border frame behind each window, expanded past the window's own edges, with a floating title bar hanging off the top-left corner. The frame's corners are chamfered by an amount inferred from the window's own border rounding, so the border peeking out around a rounded window's corners reads as a matching diagonal cut rather than a hard rectangular corner. Border color tracks Hyprland's own active/inactive border color live, gradients included.
Config
plugin {
hyprchrome {
enabled = true # bool
extent = 12 # int, px the border extends past the window edge
follow_hyprland_border_color = true # bool, use Hyprland's own active/inactive border color instead of active_color/inactive_color below
active_color = 0xFFD063FF # focused-window border color, used when follow_hyprland_border_color is false
inactive_color = 0xFF6C6C6C # unfocused-window border color, used when follow_hyprland_border_color is false
titlebar_height = 8 # int, px height of the floating title bar
titlebar_text_size = 12 # int, px font size of the title bar's text
titlebar_font = sans-serif # string, passed to cairo_select_font_face
}
}
active_color/inactive_color take the same syntax as Hyprland's own
general:col.active_border — a single color, or several plus an optional
angle for a gradient:
active_color = rgba(ff0000ff) rgba(00ff00ff) 45deg
Installing
hyprpm add https://git.mgaction.town/darman/hypr-chrome.git
hyprpm enable hypr-chrome
hyprpm builds the plugin from source against your own installed Hyprland,
using the build commands declared in hyprpm.toml (the same cmake
invocations as below).
NixOS
flake.nix exposes packages.x86_64-linux.default, built against
pkgs.hyprland from this flake's own nixpkgs input (with Hyprland's own
compiler/stdenv, for ABI correctness). Add this repo as a flake input and
set inputs.hypr-chrome.inputs.nixpkgs.follows = "nixpkgs" (your own
system's nixpkgs input) so it's built against the exact Hyprland your
system runs - then add inputs.hypr-chrome.packages.${system}.default
directly to your wayland.windowManager.hyprland.plugins
(NixOS/home-manager) list. The package installs as lib/libhypr-chrome.so
(the lib<pname>.so convention that module derives its path from
automatically) even though the plain hyprctl/hyprpm path above uses
the unprefixed hypr-chrome.so.
Building
Requires the Hyprland headers/libs (hyprland, libdrm, libinput,
libudev, wayland-server, xkbcommon, pixman-1, cairo, etc.), ABI-locked
to the exact Hyprland build you'll load the plugin into. A pinned Nix flake
dev shell provides all of it:
nix develop
cmake -B build -S .
cmake --build build
This produces hypr-chrome.so at the repo root (not inside build/, so the
hyprctl/buildAndLoad.sh commands below can find it directly).
Developing
Load/reload the plugin into a running Hyprland session:
hyprctl plugin load "$(pwd)/hypr-chrome.so"
hyprctl plugin unload "$(pwd)/hypr-chrome.so"
buildAndLoad.sh chains build + reload for iteration. Hyprland's plugin
loader never fully unmaps a .so once dlopen'd, so reloading the same path
just re-serves the old (possibly stale) mapping — the script works around
this by copying each build to a uniquely-suffixed filename before loading it
and cleaning up prior copies. It also unloads any copy your own Hyprland
config loads (found by grepping $XDG_CONFIG_HOME/hypr for a hypr-chrome
.so path), since that one is a separate dlopen that would draw a second
frame on every window. It hardcodes an absolute checkout path at the top;
check it matches your checkout before running it.