Gabriel Brown
0c4d132ee1
Found by codex's GNOME Tweaks audit and verified against the compositor:
`hyprctl descriptions` publishes input:follow_mouse as
map: [{"separate":3},{"detached":2},{"follow":1},{"disabled":0}].
Panama labelled 0 "Never", 1 "Click to focus", 2 "Sloppy focus". So this
desktop, sitting on the shipped value of 1, has been running
focus-follows-pointer the whole time while Settings called it "Click to
focus" -- and the way to actually GET click-to-focus was to choose
"Never". Value 3 was not offered at all. hypr/input.lua carried the same
wrong claim in a comment.
The shipped VALUE is left alone. Which focus mode this desktop should
use is a behaviour decision rather than a correction, and all four are
now reachable from Settings.
Nothing could have caught this. The compositor accepts 1, reads back 1,
and the write contract passes: the value is valid, it just means
something other than the label. The only authority on what each number
MEANS is the compositor, and it publishes that. So enum-hypr-map-contract
now checks every compositor-backed enum against the published map --
that offered values exist, and that published values are offered, since
a missing one is a capability nobody can reach.
Writing it immediately found two more of the same: variable refresh rate
offered Off and fullscreen-games while the compositor publishes four
(always-on and fullscreen-only were unreachable, and fullscreen-only is
what someone wanting VRR for video rather than games wants), and direct
scanout was missing its always-on value. Both now offer everything, with
a detail line per option rather than a bare word.
Verified the contract catches the original followMouse gap and a value
outside the map.
Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L
51 lines
2.3 KiB
Lua
51 lines
2.3 KiB
Lua
-- ─────────────────────────────────────────────────────────────────────────────
|
|
-- Input
|
|
--
|
|
-- Deliberately GNOME-like: click-to-focus, no focus-follows-mouse, no mouse
|
|
-- acceleration changes. The goal is that muscle memory transfers untouched.
|
|
-- ─────────────────────────────────────────────────────────────────────────────
|
|
|
|
local prefs = require("prefs")
|
|
|
|
hl.config({
|
|
input = {
|
|
kb_layout = prefs.get("keyboardLayout", "us"),
|
|
kb_variant = "",
|
|
kb_model = "",
|
|
kb_options = "",
|
|
kb_rules = "",
|
|
|
|
numlock_by_default = prefs.get("numlockByDefault", true),
|
|
|
|
-- GNOME's defaults are 500ms delay / 33Hz repeat.
|
|
repeat_delay = prefs.get("keyRepeatDelay", 500),
|
|
repeat_rate = prefs.get("keyRepeatRate", 33),
|
|
|
|
-- 1 = FOLLOW. The window under the pointer takes focus. This comment
|
|
-- previously claimed 1 was "click to focus, GNOME's behaviour", which
|
|
-- is the opposite of what Hyprland does -- `hyprctl descriptions` gives
|
|
-- map: [{"separate":3},{"detached":2},{"follow":1},{"disabled":0}],
|
|
-- so click-to-focus is 0. Changing the shipped value is a behaviour
|
|
-- decision rather than a correction, so the value is left alone and
|
|
-- only the description is fixed; Settings exposes all four.
|
|
follow_mouse = prefs.getInt("followMouse", 1),
|
|
|
|
-- Softens follow_mouse: with this off, focus changes only when the
|
|
-- pointer crosses a window boundary, not on every movement inside one.
|
|
-- Still focus-follows-pointer, just less twitchy.
|
|
mouse_refocus = false,
|
|
|
|
-- Flat pointer response, no acceleration. Matters for gaming.
|
|
sensitivity = prefs.get("pointerSensitivity", 0),
|
|
accel_profile = "flat",
|
|
|
|
-- Clicking a floating window raises and focuses it.
|
|
float_switch_override_focus = 2,
|
|
},
|
|
})
|
|
|
|
-- Desktop machine: no touchpad, no gestures worth wiring. If a laptop ever
|
|
-- runs this config, add touchpad settings in overrides.lua.
|
|
|
|
return true
|