Why haven't you just used niri instead of forking sway to scrollable wm? #200
-
|
Just a question. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
I wrote scroll when I decided to archive hyprscroller (my scrolling layout plugin for Hyprland), which was developed in parallel to niri. So even though niri and scroll are based on the same ideas (PaperWM), during the development we took different paths. At some point, dealing with the Hyprland API became a problem, I had limitations and spent a lot of time adapting to changes, so I decided to look for something that gave me stability. This was in March 2025. I looked at niri, and even though I thought it was a great project, it didn't do what I wanted, I was used to my hyprscroller workflow. I wanted to transition to something in little time, and sway provided a very stable and powerful starting point. It was more "complete" than niri, only missing the scrolling workflow, and it was written in C, with the support from wlroots. It only took me a few weeks to have a prototype, and I have been using scroll as my daily driver since then. sway is a robust code base and I get lots of features I don't need to develop by forking sway. That gives me time to focus on pure workflow features. It is more adapted to my needs than niri would ever be, because many of the features I added to scroll would probably not be accepted in niri. scroll and niri are two projects that started from the same idea, but evolved differently. Even though scroll is relatively newer, I started with PaperWM, even had a PR there, then, when I got hooked into scrolling window managers, I wrote hyprscroller, and now scroll. So it has been a long trip of already several years. When it started, niri wasn't there, so I got used to doing things my way. I think niri is great, and I recommend it to anyone that doesn't need some of the features scroll provides. It has thousands of users instead of dozens, so it is probably more battle tested. I will keep on doing my thing, because I use this for work, and it does exactly what I want, and I can experiment with new ideas as I wish, while having quite a stable framework. If other people enjoy it, great, if not, I don't really mind. |
Beta Was this translation helpful? Give feedback.
-
|
Nice write thanks! I do really enjoy it!(: |
Beta Was this translation helpful? Give feedback.
-
|
There are many differences. If you don't find any, that means you don't need scroll and should use niri, for the reasons explained above: much better support through a big user base. scroll is more keyboard centric, you don't need the mouse at all except to interact with applications that require it. Even overview/jump modes favor keyboard interaction. There are columns of full size windows, and good support for portrait mode monitors with transposed layouts. There are things like content scaling, and workspace scaling, trails and trailmarks, scratchpads, spaces, desktop integrated X11 mode, HDR and colorimetric capabilities. Ultra-wide monitor support and split workspaces. Lua API and personalization through scripts. and many other small features I added because I wanted to. |
Beta Was this translation helpful? Give feedback.
-
|
One thing you won't be able to get with niri, afaik: stable ("named"), separate workspaces with horizontal and vertical scrolling within each workspace (not globally). In scroll it's super easy to define per-project or per-topics workspaces (just like in sway) but, thanks to scroll, each workspace offers an infinite "canvas" so managing multiple windows is greatly improved. |
Beta Was this translation helpful? Give feedback.
-
|
Not that I'm suggesting a rewrite/switch, but do you have any thoughts about the new river window manager protocol? |
Beta Was this translation helpful? Give feedback.
-
What would be the advantage of that versus staying close to sway? |
Beta Was this translation helpful? Give feedback.
I wrote scroll when I decided to archive hyprscroller (my scrolling layout plugin for Hyprland), which was developed in parallel to niri. So even though niri and scroll are based on the same ideas (PaperWM), during the development we took different paths.
At some point, dealing with the Hyprland API became a problem, I had limitations and spent a lot of time adapting to changes, so I decided to look for something that gave me stability. This was in March 2025. I looked at niri, and even though I thought it was a great project, it didn't do what I wanted, I was used to my hyprscroller workflow.
I wanted to transition to something in little time, and sway provided a very stable and powerful…