fix: scroll viewport to focused window on Hyprland scrolling layout

[justindotdevv]

fixes #1329

On Hyprland's scrolling layout, the window switcher focuses the target window but doesn't scroll the viewport to reveal its column. This is because focuswindow only updates compositor-level focus without notifying the layout to adjust the viewport.

Fix: Batch dispatch layoutmsg fit active alongside focuswindow. This tells the scrolling layout to scroll the viewport to the focused column. It's a no-op on other layouts (dwindle, master)

[aurelleb]

any reason this is in draft state? looks good to me?

[justindotdevv]

doing testing on my machine to ensure it is working as intended

[justindotdevv]

Root cause was action timing rather than just the Hyprland IPC command.

Vicinae was calling focusWindowSync() immediately when the action fired, before the launcher had actually hidden. On Hyprland, the launcher often runs as a layer-shell surface with exclusive keyboard interactivity, so on same-workspace switches Hyprland was still dealing with Vicinae’s layer shell when the focus request arrived. In practice that meant the cursor warped to the target window, but the target did not reliably become the effective focused window soon enough for scrolling follow-focus to kick in.

That also explains why cross-workspace looked better: dispatch focuswindow changes workspace first in that case, and that larger workspace transition masked the sequencing problem.

Why previous iterations failed:

• fit active moved the viewport but incorrectly resized the target column.
• center in the same batch still ran too early to be reliable.
• even the later “focus first, then center after polling” workaround was still happening before Vicinae had fully hidden.

Final fix:

• defer focusWindowSync() until after the launcher has actually hidden
• then run the Hyprland focus request
• keep the scrolling-specific layoutmsg center follow-up in the Hyprland backend for same-workspace scrolling

With that sequencing fixed, same-workspace switching now behaves correctly on Hyprland scrolling without the fit active resize side effect.

[aurelleb]

this workaround seems very convoluted to me.

It looks like 9fb1f6d fixed this for some people? I'm assuming this didn't fix it for you?

[justindotdevv]

It looks like 9fb1f6d fixed this for some people? I'm assuming this didn't fix it for you?

yea it did not fix it for me, this pr currently fixes it for me. this fix does touch a lot more files than i expected. after many iterations this is what i can provide unfortunately.

[justindotdevv]

out of curiosity i pulled the latest commit and tested it. it worked for me. traced the fix to 9ce527e. exclusive keyboard interactivity was preventing the compositor from cleanly handing off focus, so the scrolling layout's follow_focus never triggered. downgrading to OnDemand lets the focus transfer work properly.

[aurelleb]

oh okay, interesting. I guess that could be considered an Hyprland bug no? If so I guess we can close this and maybe document the workaround?