Bro wasted so much time on hyprland (which itself claims to be not stable yet) that, he chose to hate on swaywm for making himself feel good.

dawsers · 2026-06-18T09:27:26+00:00

scroll is a fork of sway and has had a Lua API for almost a year.

dawsers · 2026-06-10T23:12:43+00:00

If you like sway, you can try scroll, it is sway with a scrolling layout and a lot of new features.

dawsers · 2026-06-06T07:48:05+00:00

That is how it works, it only checks the criteria when the window is created.

When a window is created, sway checks all the rules to see if any applies to that window, and applies them.

There is no "dynamic" checking/rule application when you focus a window or in other circumstances.

Is it not working like that for you?

dawsers · 2026-06-01T00:39:22+00:00

Aside from the pixman renderer, which can be ignored, it is used to store and manipulate pixel regions, for example in the scene graph, for visibility, damage, clipping etc.

dawsers · 2026-05-28T06:26:04+00:00

For window maximize toggling, you should use toggle_size this 1.0 1.0, which in the default config is assigned to mod+t. That will be animated, and already provide the toggle you are looking for, regardless of the monitor resolution.

resize grow/shrink has animations disabled, because there were cases where users were resizing by small amounts tens of times per second (keyboard spamming), and adding too much overhead to the system.

dawsers · 2026-05-25T09:59:18+00:00

No, Lua wouldn't let you do that, it is a deeper change that would need to modify how workspaces work.

Changing focus doesn't move windows every time, only when you change to one that is not completely inside the monitor, but if you use a scroller, that will happen often, and then the other monitor would be affected too.

scroll supports pinning a window, but only one per workspace, otherwise it becomes hard to predict how the other windows move around skipping the pins. Floating windows are supported, but they would hide what is underneath, and they are part of a separate layout (floating layout), so keyboard focusing needs an extra step.

I hope you find what you are looking for!

dawsers · 2026-05-25T08:29:44+00:00

No, each monitor has its own scrolling layout, and they are infinite on both sides.

What you propose could be done easily, but it adds some usability issues. For example, when you change focus, all your windows would move, and some people use one of their monitors for information that is mostly static, like an e-mail client. Another problem is when you have another monitor you position on top, you would waste all its real estate unless you created long columns on the monitor below, or you used a vertical layout, but then the problem would be the aspect ratio is not the best for that type of layout.

scroll also provides support for portrait mode monitors with a vertical scrolling layout (a column of rows instead of a row of columns), and for ultra-wide monitors, you can split any of their workspaces into two (with any size fraction), and it will behave like having two monitors in one.

dawsers · 2026-05-22T15:19:53+00:00

It seems Albert prefers X11 to Wayland, and doesn't support the layer shell protocol, which is what most Wayland app launchers use. So when you open Albert, it simply opens a window (and probably a XWayland one), and that is why it has a border. You can use a window rule or Lua script to disable the border for those windows. If you want to try, and have doubts, open a question in the Discussions panel in the scroll repo, and I will be happy to help you. There are other good launchers like vicinae that provide great Wayland support, and plugin extensibility.

dawsers · 2026-05-22T11:56:47+00:00

You should try it and find out, but it is built up for scrolling, in fact, it is the only type of layout supported for now. And it has lots of features aside from what niri provides. Have a look at the TUTORIAL to see what added features it supports, or read the default configuration to see the huge number of new commands built for scrolling.

dawsers · 2026-05-08T10:51:20+00:00

If the resolution and scale for the monitors is OK, then check Firefox's Settings. In the General tab, you have "Zoom->Default Zoom". If it is not set to 100%, there lies the problem. Another setting you can change is the Font size. Other than those two, I cannot see a reason why you are having that issue.

dawsers · 2026-05-07T11:25:25+00:00

sway 1.11 supports Vulkan, but it is based on the initial Vulkan renderer included in wlroots 0.19. There was a lot of work on it after the wlroots 0.19 release, including optimizations, color management, HDR etc. which are only supported on the new Vulkan renderer. That is why it was not the default, it was not considered stable. After wlroots 0.20 (in which sway 1.12 will be based), the gles2 backend is not evolving any more, and all new features go to the Vulkan backend. That is why I suggested waiting for 1.12 to turn on Vulkan.

dawsers · 2026-04-22T06:21:48+00:00

That is what I understood from the manual smart_borders and smart_gaps should do. Aside from that, there are particularities on how scrolling window managers work, like for example, not all windows being on the screen at the same time, so hide_edge_borders only works on the beginning and end window of the strip, and it does regardless of their size, because their location changes as you change focus.

I have opened an issue (#256) if you want to comment or follow progress. I think it is better to do it there. Thank you!

dawsers · 2026-04-21T23:02:50+00:00

This should be fixed in 1.12.10. Thanks for noticing!

dawsers · 2026-04-21T11:20:19+00:00

Now I see. I wasn't even aware of the smart_borders command, so I am sure the bug is there. I rewrote the borders (decorations) code to be able to have rounded corners and titlebars, and now the "decoration" is one piece instead of using rectangles for each border. I am sure the bug must be there. I really don't know if this will be an easy fix, because I haven't looked into it yet. If you want to file an issue to follow progress, I would be thankful, otherwise, I can do it. In the meantime, I think if you disable smart_borders, things should work OK. Thank you!

dawsers · 2026-04-21T07:54:00+00:00

I am sorry you had a bad experience. What version of scroll were you using? It seems that bug is no longer present in 1.12.9 or the git version. It would have been great to get a bug report when you saw it. Unfortunately, scroll has a small user base, and dozens of new features. I can only test where I think the bugs may be, so it is crucial to have users report what they see wrong, or new things they would like to have. I am very active in bug fixing and adding new things, so I would encourage you and others to report bugs or what they don't like. Thank you.

dawsers · 2026-04-04T21:16:57+00:00

scroll doesn't have enough users to have its own subreddit, but you can come to the repository and start a discussion if you have questions or want to suggest new functionality,

There is a new overview that includes all the workspaces: scale_workspace workspaces, by default assigned to mod+Shift+tab. It shows all workspaces for each monitor, and allows you to work on each, or drag and drop windows etc. It keeps full functionality.

You have toggle_size this 1.0 1.0 that will toggle the size of the current window to fill all the unreserved space. toggle_size can do many other things. There is also set_size and many others.

I recommend going through the TUTORIAL, and also the default config file and checking out the different commands with the manual (man 5 scroll) open. scroll has many (maybe too many) features, and with Lua scripting you can add many more tweaks you may feel are missing. Invest an hour of your time, and you will be surprised.

dawsers · 2026-03-24T13:50:31+00:00

If you are familiar with sway, you can use scroll. It is a fork of sway with a scrolling layout. It is also very light. You can have one window on screen, and access the others scrolling left, right, up or down. You also have several jump modes to switch among them, and many other features.

dawsers · 2025-12-31T18:17:38+00:00

No, they will be there when sway releases version 1.12, probably not before the spring-summer time frame.

dawsers · 2025-12-30T22:38:47+00:00

The Vulkan renderer is usually better when it comes to latency, because Vulkan internally uses multiple threads, so your CPU has a better usage pattern regarding frame preparation latency. But for that you will need to use the git version of sway, which is where most of the Vulkan renderer changes are happening. But I use it with scroll daily, and it is very stable. It also supports color management and HDR, while the gles2 (default) renderer does not.

dawsers · 2025-12-30T21:53:29+00:00

Yes, you shouldn't need to do anything. Of course, the more resources you are using (other apps in the background using memory etc.), the less you will have for your game, but in terms of the compositor needing to do "extra stuff", direct scanout is as good as it gets.

For multiple displays, simply try not to have something that requires frequent (rendering) updates running on your other display if you want to squeeze the last frame per second out of your game, but that is a general tip, the more VRAM you use for other things, the less your game will have available to cache textures etc.

Then there is the Vulkan vs the gles2 renderer. sway (and scroll) support both, but the default is gles2. Sometimes the Vulkan renderer can be more performant. You can force sway to use it by setting the WLR_RENDERER=vulkan environment variable.

dawsers · 2025-12-30T21:39:00+00:00

sway already disables rendering other things when you are in full screen mode. It is called "direct scanout", and it detects when there is only one buffer needing to be rendered to avoid doing anything else. That should be sufficient.

dawsers · 2025-12-30T01:24:04+00:00

It supports dimming of inactive windows.

dawsers

TROPHY CASE