Free scroll mode / disabling snapping

[samdesota]

I'm coming to niri from using a custom fork of PaperWM.spoon on MacOS which I made small improvements to over a year or so.

I got tired of fighting apple so I made the leap to nix with niri recently. I've been very impressed with niri so far, but there are couple ergonomics differences that I missed so ended up forking and hacking some in on this branch.

The main thing I did is make it possible to freely move the desktop around without any snapping. It's a little jank right now, I just commented out the snapping code to make this work, but it mostly works with a couple bugs. I use niri with a trackpad and this makes niri feel much smoother for me with three finger swiping to move around.

I'm creating this issue to see if you would consider a more complete PR that adds an option to disable snapping windows to the left / center / right of the screen. I'd also like to add momentum-based scrolling to this, but one step at a time

[samdesota]

My thought is that snapping would only happen when a window focus changes.

[YaLTeR]

So I'm not sure this makes sense. Why would you want no snapping at all? I understand adding snapping to monitor center for the gesture, but why none at all?

[Systemabel]

Here is a use case I run into often in my dev environment: I have vscode sitting half off-screen while I have firefox fully onscreen. I'm looking at documentation in firefox, and I want to add a line to the document I'm working on in code. However, because of how content is formatted/rendered in both applications, I can't size both to fit on the screen at once and maintain the same spacial orientation, and my adhd brain jumpstarts when the workplace snaps to the next window I focus on. I'd prefer to put the viewport exactly where I like it, then have my mouse to capture window focus. So in that instance, I move my mouse over to vscode, click on the line I want to edit, then begin typing the solution that I'm reading from firefox without having to change any spacial awareness. When I think about it this way, I guess it's an accessibility feature.

In that instance, the direct issue is that focused windows snaps to be fully on screen and won't focus if they're partially off screen, or else they snap onto the screen if I allow it, but that's disorienting. I hope this is a sufficient explanation for why this feature is desirable. I know I can sometimes be verbose and a little bit wandering when I explain things.

[mastoca]

@Systemabel I regularly have same challenges you describe as well. I know scroll will work in a half visible window but usually I want to paste/type into the half window without it coming into focus or moving. very tiring experience.

[mastoca]

I would love to have a short cut or key command to activate the snap when I want it. If this feature was available I would disable ALL snapping and move it to a keybind so I snap when I want instead...the rest of the time the entire view space would be set to no-snapping and keyboard focus follows mouse. this would de-couple and let me control niri when I want snapping.

[samdesota]

Center snapping often works well, but sometimes you want the content of 2 or more windows fully on the screen but snapping gets in the way. I prefer to use a keyboard shortcut to center things ad-hoc when I want that, so that the snapping isn't preventing me from shifting windows exactly how I'd like. Left and right snapping feels not great with the gesture to me, especially for when there is only a couple of windows open and niri wants me to snap it way to the side on my 32:9 monitor.

It's kinda just a feel and a big part of it as ultra-wide monitor support. Snapping just feels like unnecessary jerkiness, I can use shortcuts to activate the grid like centering or aligning left or right when needed. Also I use focus on hover which is part of it.

Maybe this recording helps give a sense of how it feels to use niri with no snapping, you can also see some of the jank with my current branch where niri won't let me fully move the focused window off the screen, which I'd like to fix.

2025-03-27.12-22-38.mp4

[YaLTeR]

I guess it's a different story with such a wide monitor yeah

[samdesota]

I think I would like snapping on most keyboard actions, just not on focus follows mouse and the scroll gesture.

Maybe this could look like

• An option to disable snapping when scrolling with the gesture
• An option to allow focus follows mouse to focus windows partially outside the view port, but prevent scrolling. Might sound strange but interacting with windows partially outside the view port is something I do pretty frequently
• All other focus actions continue to use the current left / right or centering behavior
• Add a command to trigger bringing the currently focused window fully on the screen, may be one already

[YaLTeR]

focus windows partially outside the view port, but prevent scrolling

this is Not Going To Work because it's fairly well baked into all parts of the code to always try to bring the focused window into the view

[samdesota]

l did manage to get something like this working, I added flag to the function that computes scrolling into view and then propagated it through scrolling.rs. https://github.com/YaLTeR/niri/compare/main...samdesota:niri:sdesota/scrolling-changes?expand=1#diff-24e00052eeb5d3cfe29afaf02fbdd632f2cab43f08a6693be62c3510cbae8574R5139

[alicealysia]

I'd also be a fan of having the option to disable snapping. Even if it were a blanket on/off. I generally prefer navigating with mod+middle click and snapping can make that a little challenging

[mastoca]

I too would be happy with a single option to enable/disable all snapping. I've added an extra trackpad on my left hand to glide around and snapping just fights in certain edge cases.

[Systemabel]

Hey y'all, I've been poking around online for a while to see if there were any options or scripts etc that would disable column snapping on niri. I'm glad I found this conversation so I can just say that I'd also love this feature. I was hypothesizing that if I were to figure out how to create this feature, I would probably create a keybind that toggles snapping or causes a one-off snap for the focused window, since most of the time I'd prefer free-scrolling, but in some instances, particular windows should be snapped to (such as full-screen windows) --> that leads me to think it be logical to have an option under window rules too. I also brainstormed that the ideal implementation for this feature would include momentum scrolling.

I think the push for this feature is about design philosophy for ui's to be intuitive, easy to learn, and allowing room for power-users to tinker. Niri accomplishes these, imo, effectively and even so, I intuitively thought that a toggle for free-scrolling would have been baked in when I discovered scrolling WM's in general, and I'm slightly surprised that this sort of feature isn't normalized. It just "makes sense" in my mind, especially in relation to the design philosophy of scrolling WM's. I think of scrolling WMs metaphorically like having a camera on a rail pointed at a bulletin board of application windows, if that makes sense. I want my rail-mount dolly to be smooth, not notched.

It took me a while (a few days of intermittent google searches and experimenting with various key phrases) to find this conversation and I nearly opened a new feature request which means a) I didn't know where to look, and more importantly b) there are probably a number of niri users who want this feature but aren't as meticulous at looking for existing conversations about it.

Here are some questions: how hard is it to implement a feature like this? Is it possible we could bump this up to tracking in issues as an enhancement/feature? Is there already an issue open for this that I missed? I skimmed through the current issues, and there are many open so I understand not wanting to add another.

Nonetheless, I've been thoroughly enjoying my experience on niri so far, so my hat goes off to YaLTeR and all the other contributors!

[b0o]

Take a look at #1929, I haven’t had much time to work on it lately, but I think the PR touches some of the code paths that would be involved in implementing free scrolling.

[yebei199]

I think this feature is very useful and truly appealing, it’s like a kitten gently scratching at my heart.

[mustofa-id]

This is my case when I try to copy text between two windows (50% and 80%). The window shifts and snaps when focus changes, which disrupts the layout during text selection. An option to disable snapping would greatly improve this workflow.

niri-win-snap-issue.mp4

[EzeKoren]

Hey everyone, I'll be following this thread because this is a feature that I really wish was configurable. I come from daily driving PaperWM on my laptop and what I'm used to is that I can scroll with three fingers and land on whatever position I want the window to stay. This is a very intuitive workflow to me so when trying to scroll I find the windows snapping somewhere else other than the position I scrolled to is very distracting. I hope in the near future a setting can be added that allows disabling snapping when scrolling through gestures or the scroll wheel. Cheers!

[weavejester]

I'm also interested in getting free scrolling working, as it's currently the main advantage PaperWM has over Niri. There are three parts to this feature that I can see:

1. An option to disable window snapping on scroll
2. An option to add momentum to scroll
3. An option to prevent window focus from changing on scroll

The third seems to require the most work, since "it's fairly well baked into all parts of the code to always try to bring the focused window into the view".

I don't currently have the time to work on this myself, but I would be very happy to financially sponsor an experienced Niri developer to work on the first part of this feature.

[weavejester]

I've gotten a little time of late, so I've implemented part 1 of this feature with a new option:

gestures {
    free-view-scroll
}

The implementation is on my branch: https://github.com/weavejester/niri/tree/free-view-scroll

I eventually plan to submit a pull request, but I want to ensure that there's no issues with it first, so I'm going to be using my dev branch as my main WM for a few weeks just to ensure everything operates correctly..

[bczhc]

An option to allow focus follows mouse to focus windows partially outside the view port, but prevent scrolling

Exactly what #1877 does?

In cases like comments in #1347 (reply in thread) and #1347 (comment), I believe the PR (#1877) above helps and I've used that for a long time, though I don't use that that frequently but when I need it, the view-lock feature just is useful. There are discussions about it: #2538

1.mp4