Feature/gradient border #4

Merged
darman merged 3 commits from feature/gradient-border into develop 2026-07-29 23:03:02 +02:00
3 changed files with 22 additions and 2 deletions
Showing only changes of commit 375cfe1f00 - Show all commits
+2
View File
@@ -42,6 +42,8 @@ This builds and hot-reloads the plugin into a running Hyprland session in one st
The script copies the built `.so` to a uniquely-suffixed filename (`hypr-chrome-<random>.so`) before loading it, and unloads/deletes prior copies. This works around Hyprland's plugin loader never fully `dlmunmap`ping a `.so` on unload — reloading the exact same path just re-serves the stale old mapping instead of the freshly built code. The script copies the built `.so` to a uniquely-suffixed filename (`hypr-chrome-<random>.so`) before loading it, and unloads/deletes prior copies. This works around Hyprland's plugin loader never fully `dlmunmap`ping a `.so` on unload — reloading the exact same path just re-serves the stale old mapping instead of the freshly built code.
It also unloads whatever copy the user's own Hyprland config loads (grepped out of `$XDG_CONFIG_HOME/hypr` rather than hardcoded, since a home-manager-installed one lives at a `/nix/store` path that changes on every rebuild). That copy is a separate `dlopen` with its own decorations, so leaving it loaded draws two frames per window.
Manual equivalent: Manual equivalent:
```sh ```sh
+5 -2
View File
@@ -87,5 +87,8 @@ hyprctl plugin unload "$(pwd)/hypr-chrome.so"
loader never fully unmaps a `.so` once `dlopen`'d, so reloading the same path 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 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 this by copying each build to a uniquely-suffixed filename before loading it
and cleaning up prior copies. It hardcodes an absolute checkout path at the and cleaning up prior copies. It also unloads any copy your own Hyprland
top; check it matches your checkout before running it. 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.
+15
View File
@@ -21,4 +21,19 @@ for old in hypr-chrome.so hypr-chrome-*.so; do
[ "$old" = "hypr-chrome.so" ] || rm -f "$old" [ "$old" = "hypr-chrome.so" ] || rm -f "$old"
done done
# The session also loads the plugin declaratively from the personal Hyprland
# config (home-manager's wayland.windowManager.hyprland.plugins, which lands
# as a /nix/store/.../lib/libhypr-chrome.so). That copy is a separate dlopen
# with its own decorations, so leaving it loaded means every window gets two
# frames drawn on top of each other. Its store path changes on every rebuild,
# so read it back out of the config instead of hardcoding it (-R to follow
# home-manager's symlinks into the store).
HYPR_CONFIG_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/hypr"
if [ -d "$HYPR_CONFIG_DIR" ]; then
for configured in $(grep -Rho '/[^[:space:]"'"'"']*hypr-chrome[^[:space:]"'"'"']*\.so' "$HYPR_CONFIG_DIR" 2>/dev/null | sort -u || true); do
[ "$configured" = "$DIR/$NEW_SO" ] && continue
hyprctl plugin unload "$configured" >/dev/null 2>&1 || true
done
fi
hyprctl plugin load "$DIR/$NEW_SO" hyprctl plugin load "$DIR/$NEW_SO"