river VS bspwm

More info on the wiki https://github.com/riverwm/river/wiki

Here is the related github issue

If you can get past some minor wayland related annoyances, river is pretty easy imo, you can write a config in whatever format you want, it just needs to be an executable file, the most common type is a shell script. The actual configuration happens by calling the riverctl program from the file, which from what I've heard is a similar method compared to bspwm.

Coming from awesome you may find river more to your liking than sway.

River crashed everytime I closed Chromium. The developer fixed it in 5 minutes :)

I've written a plugin that implements the river-layout-v3 wayland protocol in Hyprland. This means you can run something like rivertile, river-luatile, rivercarro or kile as a layout provider.

Author here. And yeah, as of 0.6.0 it supports master stack - I just called it stack main. I was in fact inspired by river: https://github.com/riverwm/river. River is really promising but is still in very early development. Sway on the other hand has been around for a long time and I, for now, prefer that stability.

In my very specific case, I'd probably start by taking a look at how animations were previously implemented in river, and then I'd pay careful attention to that transform matrix at the end. I'm not super crazy about the implementation using timers to drive it (versus interpolating where the transform should be across a deadline), but I guess they were going for smoothness.

riverwm wayland compositor

The biggest QOL improvements imo are found in the approach to the user-facing API design.

Compare basic multi-monitor commands in something like bspwm[1] or yabai[2][3] to twms on Windows where this is typically handled transparently by directional `move` and `focus` commands understanding monitor boundaries.

Besides this, Whim has implemented a very functional ctrl+p style command palette which provides a great interface for more advanced on-the-fly/one-time window manager interactions.

With komorebi I think that having different border colours to indicate different types of containers is very helpful (one colour for single window stacks, a different colour for monocle containers, a different colour for stacks with multiple windows), as well as custom window-based work area offsets[4] (so if you have an ultrawide monitor with only a single window on a workspace, you can add offsets to the sides so it doesn't stretch across the whole width and give poor usability).

It's not really any one "big thing" but rather a difference in approach which adds up over many small design decisions.

[1]: https://github.com/baskerville/bspwm/issues/563

Bspwm is a window manager. Configuration happens in $XDG_CONFIG_HOME/bspwm/bspwmrc, as per stated here: https://github.com/baskerville/bspwm

Use BSPWM. It supports right clicks by default and its modular. You might want to look for status bars that work with it, slstatus does not work. Good luck, supremacist!

I had not heard of bspwm but I am a fan of telling WMs. Looking at the documentation now, I really like the pragmatic approach lol https://github.com/baskerville/bspwm

If you use the bspwm off of github instead of the old 0.9.10, you can use bspc node @parent -y next to cycle the split type of the parent of the focused. I added it ~1.5years ago, after baskerville added node -y horizontal and node -y vertical to set the split type of a node to vertical/horizontal ~2 years ago.

Also bspwm's JSON generation and parsing is not great. If you have a window with quotes in its class name, bspwm, when dumping it, will not escape them generating invalid JSON (e.g. {"className":"the "cool" window",) that jq will not be able to read, and even worse, bspwm itself will not be able to read. (Yes, if a window's class name contains a " character, bspwm will fail to reload after you run wm -r #1362).

Just follow this guide