darman/hypr-chrome
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Unload the config-installed plugin copy in buildAndLoad.sh

Browse Source 
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>
This commit is contained in:
darman
2026-07-29 20:36:41 +02:00
co-authored by Claude Opus 5
parent b9dafe2ce1
commit 375cfe1f00
3 changed files with 22 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CLAUDE.md
+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.
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:
```sh