4 ms·

I settled on river¹ after a couple of decades with awesomewm. Tiling and tagging work in a way you'd expect coming from awesomewm, but nothing else does. I ma

by JNRowe 4mo ago

I settled on river¹ after a couple of decades with awesomewm. Tiling and tagging work in a way you'd expect coming from awesomewm, but nothing else does. I made my mind up because having to use workspaces and manual tiling is a far harder sell than implementing the functionality I want on top of a decent base. If anything it reminds me more of the experience with using awesome v2(before lua); you generate a config file for the base WM, and then build up external tooling to drive it how you see fit. The experience has been quite pleasant, but I do enjoy twiddling. ¹ https://codeberg.org/river/river https://codeberg.org/river/river Edit: I just checked my dotfiles. Awesome went in on 2008-06-09, and river on 2024-06-30. Happy and largely uneventful two years on river.

NoboruWataya 4mo ago
I had seen river but for some reason didn't look too much into it. I think it's because at first glance it looks like a protocol that you can build a WM on, rather than a WM itself, but I guess it's probably easy to build your own tooling over it (a lot easier than "building your own WM" in the traditional sense)? I'll give it a look - thanks!
- JNRowe 4mo ago
  If you want an out of the box test then playing with river-classic¹ is probably a good place to start. It gives a feel for where you can go, without having to put too much effort in. For example, it has pluggable layouts where instead of pulling in a lua module(such as awful.layout) in awesome you'll run an external process which handles events. You can even run multiple managers and switch between them with bindings, or write a custom one to scratch that itch. If you're happy with just awful's .suit.tile.right and .suit.max then basically any backend will do. This is why it feels like a reasonable path off awesomewm to me. I always considered awesomewm to be the WMConstructionKit, and while river changes how you interact there is still a nice route to extensibility. The newer direction even more so than the -classic offshoot. ¹ https://codeberg.org/river/river-classic https://codeberg.org/river/river-classic

by JNRowe 4mo ago

NoboruWataya 4mo ago

I had seen river but for some reason didn't look too much into it. I think it's because at first glance it looks like a protocol that you can build a WM on, rather than a WM itself, but I guess it's probably easy to build your own tooling over it (a lot easier than "building your own WM" in the traditional sense)? I'll give it a look - thanks!

JNRowe 4mo ago
If you want an out of the box test then playing with river-classic¹ is probably a good place to start. It gives a feel for where you can go, without having to put too much effort in. For example, it has pluggable layouts where instead of pulling in a lua module(such as awful.layout) in awesome you'll run an external process which handles events. You can even run multiple managers and switch between them with bindings, or write a custom one to scratch that itch. If you're happy with just awful's .suit.tile.right and .suit.max then basically any backend will do. This is why it feels like a reasonable path off awesomewm to me. I always considered awesomewm to be the WMConstructionKit, and while river changes how you interact there is still a nice route to extensibility. The newer direction even more so than the -classic offshoot. ¹ https://codeberg.org/river/river-classic https://codeberg.org/river/river-classic