feat: scrolling layout

[BarutSRB]

Transform scroll layout from flat 1D horizontal strip to sophisticated 2D column-based architecture:

Column Architecture:

• Refactor from flat window list to column-based structure with ColumnId system
• Support multiple windows stacked vertically within each column
• Per-column width and per-window height customization
• Bidirectional synchronization between flat and column representations
• Comprehensive column operations (insert, remove, swap, move, resize)

2D Window Management:

• Vertical window operations within columns (move up/down, swap)
• Cross-column operations (move between columns, consume, expel to new column)
• True 2D navigation with up/down/left/right movements
• Intelligent selection tracking across both dimensions
• Advanced layout calculation with viewport culling and proper gap handling

Smooth Animation System:

• 60 FPS animation ticker thread for continuous updates
• Multiple easing curves (EaseOut, EaseInOut, Spring with damping/stiffness)
• Animated scroll offset transitions for smooth navigation
• Integration with layout engine for frame-based rendering

Niri Window Manager Compatibility:

• KDL config parser for reading Niri configuration files
• Complete Niri IPC protocol implementation with 15+ commands
• Niri CLI integration via rift-cli niri subcommand
• Support for Niri keybindings and workflow patterns
• Column-based commands (focus, move, resize, consume, expel)

[alle-ox]

@BarutSRB plz format code using cargo +nightly fmt --all for removing unnecessary formatting changes

[BarutSRB]

@alle-ox Will do either tonight after work or tomorrow morning.

[tshort]

I'm an outsider, and I'm not really qualified to review Rust code, so take these suggestions with that in mind. I like where you are going in terms of a 2D model. Here are some initial issues and thoughts:

• Basic left-right scrolling is still clunky. Windows can be focused but be off screen. Given that, I'd mark this pull request as a WIP.
• It still uses the screen height as the base unit. That's odd to me. I think it should be the screen width.
• The cursor selecting issue is still present. So far, that seems to be a me-only bug.
• It's nice to have the new CLI commands to support a more advanced scrolling mode. I'm not sure having the command called "niri" is the best way to integrate them.
• I would not introduce a new configuration format. That should be in another PR.

[BarutSRB]

@tshort thank you and good catch for the screen height as the base unit, it should definitely be the screen width.

The whole thing is still WIP I just wanted to get on track with the scope and get some input before I devote fully, as nothing worse then going back and doing major changes.

[tshort]

Don't put too much weight on my opinions--I'd wait for input from @acsandmann.

[BarutSRB]

@acsandmann @alle-ox @tshort I have removed all the Niri compatibility layers, KDL, and have refactored the scroll layout to make it mentally easier as it was 2,800 lines of code. There is still work to be done, I'd like your input if possible. Here is the config I used for testing: https://codeshare.io/5NPV1d

[acsandmann]

please drop .idea and run cargo +nightly fmt

[BarutSRB]

please drop .idea and run cargo +nightly fmt

Pushed

[acsandmann]

rift already had an animation system so please make use of that. in addition to that i think this code is a little "verbose" and it seems to reinvent the wheel as opposed to using helpers already available in the codebase.

[BarutSRB]

@acsandmann Hi, I rewrote it completly, utilizing as much as I could from the current architecture using the main up-to-date branch.

New config setting:
[settings.layout.scroll]
# Maximum number of columns displayed at once in the scroll layout (1-5)
# This controls how many columns are visible simultaneously; extra
columns stay in the carousel.
visible_columns = 2

ALT+SHIFT+H/L (Still not perfect as I do plan on adding a command that automatically takes out a focused window from a stacked column in a newly created column to the right)

You can insert or remove a window/row from or to a column, max 3 windows/rows per column. I don't see the reason for beign more but if there is a need then we can also add that setting to the config for customization by the users.

Infinite loop left/right

TO DO:
Add resizing
Add proper removal from the column of a window to a newly created column on the right
Fix mouse_follows_focus = true, it will follow only if two windows are on same screen as soon as I scroll in any direction it doesnt do it.
Add gesture from your implementation
Figure out which of the animations is smothest for scrolling and fine tune its config settings
Open to suggestions

Config file I used is attached.
config.zip

CleanShot.2025-11-19.at.04.36.33.mp4

[tshort]

I only played with this latest a bit. Here's what I found:

• On one workspace, windows had overlap.
• I dislike the Infinite loop left/right. Some folks might like it that way, but it's not standard. If you like this, I suggest adding it as an option.
• Scrolling right, if I have extra right-side windows, when the first hidden window is focused, it shifts that window all the way to the left. I think it should mirror what happens when you scroll left. If you're on the right and moving right, newly focused windows appear as right aligned.
• CLI commands for querying windows look broken. Many windows are missing.

[BarutSRB]

@tshort Try now, the navigation should be fixed with proper window alignment based of user intent. Also the infinite scroll is a toggle in config file now infinite_loop = false should be default

I'll see what the problem is for CLI when I get soem free time as for one of the workspace windows havign overlap, I'm not sure how to reproduce it or full grasp the problem, if you can describe it a bit mroe in depth or how to reproduce it I'd appreciate it.

[tshort]

@BarutSRB, your latest commit feels much more natural. The left-right scrolling works great.

The way windows automatically fit is interesting. Maybe this could be a mode that's toggled. I know I'll have some apps I'll want to remember their width (especially full-width windows).

As for reproducing the overlap, I'm not sure what triggers it. It happens on some spaces but not others. It's not a lot of overlap (tens of pixels, maybe).

[BarutSRB]

@tshort When you have a moment, I’d really appreciate it if you could test out the latest changes ❤️

@acsandmann @alle-ox @tshort What do you think? If you have any suggestions, ideas, or run into any bugs, please let me know. From my perspective, the scrolling layout features are nearly complete, the main thing left is adding trackpad/mouse wheel navigation. @acsandmann did an amazing job on that, far beyond what I could do, but I’m happy to help however I can.

[brianwk]

I want to test this, but I have many patches applied and I'm worried that it might break something. mostly want to test it because I am curious about what is a scrolling layout. I have no idea. haha.

[tshort]

I can't keep up, @BarutSRB 😄.

Here are some notes:

• It's nice to see resizing working. It works smoothly. Full-screen toggling works fine.
• I don't see the issue with small overlaps anymore.
• For me, resizing maxes out at less than the screen width. It'd be nice to have a command to size a column to 100% width or another value.
• When windows are resized, it messes up focusing. For example, if a left-most focused window is 75% and the window to its right is 40%, a focus-right command does not scroll right. Part of the window is still offscreen.
• With resized windows, left-right scrolling is inconsistent. There are sometimes big overlaps.
• If I have two 50% windows, and I shrink the left one, the right one expands to fill the screen. I'd rather window sizing only affects the current window. There could be other commands to resize windows to fit in the current space.
• I don't have the selecting bug that the other scrolling PR had with my setup.
• CLI querying still doesn't work. The reason I was looking is to see if I could script the following command:
  • focus-down-or-next-space--If the window in focus is a single window in the column or the last window, the "down key" will move to the next workspace. Built in would be great, but it could/should be possible with scripting.

[BarutSRB]

I want to test this, but I have many patches applied and I'm worried that it might break something. mostly want to test it because I am curious about what is a scrolling layout. I have no idea. haha.

@brianwk you can just pull it to another directory build and run it with cargo and backup first the original config use the one I linked if you want to test it without affecting other rift pull/install you're experimenting with

[BarutSRB]

@tshort Thank you for testing it out ❤️

• I'll check out the resize focusing issue and work on the cli for scrolling layout.

• I'm glad some stuff you previously had problems with are fixed

• As for automatic filling of empty space when you are shrinking one column and other column expands to fill the empty space, that's meant to be for auto tiling wm but once I get the cli working for scrolling layout you might be able to script it to do what you want.

• Most of the other stuff are meant to be as I based it off Niri's scrolling behaviour as much as possible, keep in mind that some macos apps will have minimum size they will obey and below that it will simply overflow over another window (I personally have big problems with Commander One app due to it).

Were you testing with the config file i linked or using your own?

[BarutSRB]

config.txt

ALT + SHIFT + SCROLL WHEEL to test the "pixel-smooth" scrolling

[tshort]

Here are some comments on the latest changes:

• The two fingered scrolling on the touchpad makes this painful to use. I can't really use up-down scrolling with the touchpad because of it. Windows start shifting left and right, and the focused window sometimes starts changing size. It also doesn't appear that touchpad scrolling makes any changes. The windows start scrolling, then everything jumps back to approximately the original position when released.
• Left-right focusing has changed back to tending to lock the focused window on the left side. That seems unnatural to me.
• I think the "auto tiling" is bad. One of the nice things about a scrolling WM is that windows stay the same size. If I'm resizing one window, I don't want the window next to it to change. I think the "auto tiling" should be behind a flag. Scripting this to work around the auto tiling would be hard.

[tshort]

Maybe I need to try your config.

[BarutSRB]

Maybe I need to try your config.

Ah now I understand what you mean, I misunderstood you that you wanted when resizing to have empty space in between and not compact the adjacent windows

[BarutSRB]

@tshort I'm thinking that me trying to pull from main the commits in order to have the scroll layout branch synced with main where I had to manually do the merge probably lost some features that were working. So I'm thinking for now to drop the commits down to the last known feature working commit fix the CLI for it without the scroll animation just keep it keyboard centric for now and see if @acsandmann has time to add the gesture smooth scrolling. What do you think?

[brianwk]

I just tested this. It seems like it could be cool but I guess you are still working on merging it to main after the massive amount of changes done. At first I wasn't sure if I was using it right but then I realized that on my config I don't have the spaces deactivated by default. So I had to hit ALT+Z to activate it. Also I think I don't get it. Like how do I find the window I want? Currently I just do ALT+X where X is the workspace and I know my windows will be there. With this layout, I have to scroll through a bunch of different windows. I'm assuming that it's meant to be multiple workspaces not just all in one workspace.

Also to someone who wants to test it.... If you are using the config provided by Barut using "cargo run" make sure that you place a "--" before putting "--config rift.toml" to pass the configuration file to the binary args.

To be honest when I used the touchpad the scrolling was not smooth at all. I don't know how to describe it, but the windows kept "glitching" and disappearing and reappearing. It was quite strange. Also there is the usual bugs with windows floating around in Rift that are being worked on still.

Just ping me when it's ready to test again and I will give it a go. I can kind of see how it could be cool when I'm not plugged into my external monitor because I can view all of my windows at full width instead of a weird squished tile window.

Of course I have questions though.... Can we have a way to scroll to a specific window? Like let's say I have a window with "web server" and "javascript" in the title. I want to scroll to these windows with a hotkey instead of scrolling through all the windows. Possible?

Update: I still don't get it though. Like to me it just seems like stacking with extra steps. I'm gonna try your dwindle layout next...

[brianwk]

Okay I tested this further. I think that it's not intended to be used with app rules, because the scrolling didn't work when I used a configuration with my app rules in place. I couldn't seem to get the windows in the workspace to scroll. They would just flip around. Maybe I am just ignorant and I don't understand what a scrolling layout is.

I guess my vision was like, you can scroll through the windows on the workspace. But it doesn't seem to work if you only have two windows on the workspace.

Edit: Is this meant to be used with a mouse?

[BarutSRB]

Yeah niri does not use rule driven tiling layouts like dwindle, bsp, or tiles, I personally don't use it but many people love the simplicity and beauty of it. You simply use workspaces with one infinite scroll per workspace to organize everything, some people have designated workspaces for each monitor and that is pretty much it, you send windows around d workspaces/monitors (not yet supported)

[brianwk]

Yeah niri does not use rule driven tiling layouts like dwindle, bsp, or tiles, I personally don't use it but many people love the simplicity and beauty of it. You simply use workspaces with one infinite scroll per workspace to organize everything, some people have designated workspaces for each monitor and that is pretty much it, you send windows around d workspaces/monitors (not yet supported)

Looking forward to seeing the latest updates on this feature! No pressure though. 😅