Repository navigation
Floating windows (e.g. Steam) can render off-screen — a Lua auto-recovery script #10272
krys-anto
started this conversation in
Suggestions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The problem
Floating windows can end up placed almost entirely off-screen — most of the
window sits past the edge of every connected monitor, so it looks like the
app never opened. I hit this with the Steam client window (spawned at a
negative x coordinate, past the left edge of both my monitors) and had to
dig through
hyprctl clients -jto even find it. It's easy to mistake for afrozen/crashed app rather than a placement bug.
A fix, using Hyprland's native Lua config hooks
Since Omarchy configures Hyprland in Lua, this can be fixed entirely in user
config with no external daemon: a small script that watches floating windows
(tiled ones are left alone — the layout engine already keeps those on-screen)
and snaps one back on-screen if more than half its area falls outside every
monitor's usable rect.
Algorithm: for each floating window, compute its overlap area against each
monitor's usable rect (monitor bounds minus reserved bar/panel space). If
total visible area is under 50%, pick the monitor with the most overlap (or,
if it overlaps none at all, the nearest monitor by center distance), then
clamp the window's position into that monitor's bounds. It's the same
overlap-then-clamp approach used to keep a body inside level bounds in 2D
collision code.
It runs two ways: instantly on
window.open(catches a window placedoff-screen the moment it's created, before you ever see it), and as a
lightweight periodic sweep (catches a window dragged off-screen mid-session,
since there's no native "window moved" event to hook).
Install: save as
~/.config/hypr/floating-guard.lua, addrequire("hypr.floating-guard")tohyprland.lua,hyprctl reload.Suggestion
Would this be worth including as an opt-in default, so anyone hitting this
doesn't have to go digging through
hyprctl clients -jto figure out theirapp didn't actually crash?
It would fit the existing
omarchy togglepattern (same mechanism asnightlight/idle): wrap the
hl.on/timer registration behind a toggle statefile under
~/.local/state/omarchy/toggles/, wire upomarchy-toggle-floating-guard, and default it on (or off, if themaintainers would rather this be explicit opt-in). No code changes needed
beyond that — the script itself doesn't need to know it's toggleable, it just
wouldn't get
required (or its setup would no-op) when the toggle is off.Tested on Omarchy 4.0.2-1 / Hyprland 0.56.2. Happy to open a PR — including
wiring up the toggle — if this seems like a good fit.
All reactions