In the spring of 2020 I found myself hooked on Wayland thanks to
sway but increasingly frustrated with the
i3 style window management sway implements.
I tried several of the other more mature Wayland compositors
including hikari and
Wayfire but didn’t enjoy them any more
than sway. I wanted dynamic tiling window management similar to
dwm but on Wayland and without dwm’s configuration
through patching the source code approach.
As I had a newfound abundance of free time at home in front of
my computer thanks to the global pandemic that was ramping up
that spring, I decided to write my own Wayland compositor. Thus,
river was born.
Features
The core guiding principle in river’s design is that its behavior should
be predictable. This means keeping things as simple as possible, reducing
implicit state the user must keep in their head while using river.
River’s window management is based on a linear stack of windows much like
dwm. These windows are arranged by a separate program called a layout
generator. Users are encouraged to write and share their own layout
generators, they are simply Wayland clients which implement a custom
river-layout-v3 protocol. You can find links to several nice ones on this
wiki page. River
also ships with a layout generator, rivertile, that provides a few simple
layouts for those who don’t need anything custom or fancy.
Instead of traditional workspaces, river supports tags. Each window may be
assigned one or more tags and multiple tags may be displayed at once. Again,
this behavior is strongly influenced by dwm.
All configuration and control of river happens at runtime through the riverctl
tool. It can be used to create keybindings, move focus between windows,
set the border color, etc. River doesn’t have any traditional configuration
file, instead it runs an arbitrary executable on startup which is generally
a shell script invoking riverctl to setup the user’s desired configuration.
River 0.1.0
I’ve been using river as my daily driver for well over a year now, and am
happy to announce the first release today, river 0.1.0. In recent months
there has been little churn in river’s codebase and it is currently quite
stable and bug free. Because of this, people seem to have started using it.
As I plan to cause a lot more churn on the master branch in the near future
which will inevitably create new bugs and break people’s configuration,
this is the perfect time for a release.
I’d like to thank everyone who has contributed code, documentation
and bug reports to river. In particular, thanks to Leon Henrik
Plickat for his consistent, high quality
collaboration since the early days of the project. Without all of you this
release would not have been possible.
The Future of River
Although I consider river useful enough today to tag a first release, it
is not yet complete. The core functionality and standard use cases are well
supported but river is not yet nearly as flexible as I would like it to be.
I have several ideas that I plan to try out to improve river’s flexibility
and ease of customization, but this will take time. For this reason,
users should expect widely breaking changes to how river is configured
and controlled before we approach a stable 1.0 release. Fear not though,
the core functionality and spirit of river are here to stay!
If you’d like to contribute financially to my work on river, please consider
sponsoring me on GitHub Sponsors
or Liberapay. To those already donating,
thank you so much for your support!