Scroll edge windows within visible area instead of locking to far edge

[skokenes]

Say I have a workspace setup with windows like so:

A-B-C-D

Today I can use swipe / mouse horizontal scroll to bring windows B or C to the center of my monitor. However, for windows A and D, I cannot do that. For A, the swiping stops where A meets left edge of the monitor. For D, the swiping stops were D meets the right edge of the monitor. Using [ ] as the visible window boundaries, and _ as deadspace:

Max position for A, as an example:
[A-B]C-D

Max position for D, as an example:
A-B[C-D]

I work on a wide monitor, and sometimes I want to pull the edge windows center to focus them. Most common example is a code editor. So say I want "D" centered, I am trying to get to:

A-B-[C-D_]

Today in order to do so, I either have to:

1. move D to a different workspace
2. move D before C
3. make D fullscreen
4. add a dummy window on either side of D

My suggestion is that scroll limits be that edge windows can scroll to the opposite side of the window from the edge. For example, with window D, horizontal scrolling would stop at:

A-B-C[D__]

In this way, you can never scroll to a position where there are no visible windows in the strip, but the first/last window can exist anywhere within the visible area.

Would you be open to something like this? I'd be happy to take a stab at a PR.

[BarutSRB]

@skokenes hey thank you for reporting this, I'd be happy to have this as a PR but let me push first a release today (around 5PM EST) as I did some fixes and small refactors along with minimal zig rewrites of where it made sense, because if you start doing it now you will need to rewrite the PR due to changes.

Thank you ❤️

[BarutSRB]

@skokenes BTW have you tried toggling on infinite scroll in the Niri tab of the gui settings to see if it would help in your case?

[skokenes]

Yea I have, that only allows navigation to prev/next window to wrap back around to other side of list. Doesn't affect endpoint positioning within visible area; swipe/mouse scroll behavior remains the same

[BarutSRB]

@skokenes Done 1186d28