871fc7c8de
This protocol involves far too much accidental complexity. The original motivating use-case was to provide a convenient way to send arbitrary data to layout clients at runtime in order to avoid layout clients needing to implement their own IPC and do this over a side-channel. Instead of implementing a quite complex but still rigid options protocol and storing this state in the compositor, instead we will simply add events to the layout protocol to support this use case. Consider the status quo event sequence: 1. send get_option_handle request (riverctl) 2. roundtrip waiting for first event (riverctl) 3. send set_foo_value request (riverctl) 4. receive set_foo_value request (river) 5. send foo_value event to all current handles (river) 6. receive foo_value event (rivertile) 7. send parameters_changed request (rivertile) 8. receive parameters_changed request (river) 9. send layout_demand (river) And compare with the event sequence after the proposed change: 1. send set_foo_value request (riverctl) 2. receive set_foo_value request (river) 3. send set_foo_value event (river) 4. send layout_demand (river) This requires *much* less back and forth between the server and clients and is clearly much simpler. |
||
|---|---|---|
| .github/workflows | ||
| completions | ||
| contrib | ||
| deps | ||
| doc | ||
| example | ||
| protocol | ||
| river | ||
| riverctl | ||
| rivertile | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| AUTHORS | ||
| build.zig | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
river
river is a dynamic tiling wayland compositor that takes inspiration from dwm and bspwm.
Note: river is currently early in development. Expect breaking changes and missing features. If you run into a bug don't hesitate to open an issue
Design goals
- Simplicity and minimalism, river should not overstep the bounds of a window manager.
- Window management based on a stack of views and tags.
- Dynamic layouts generated by external, user-written executables. (A default
rivertilelayout generator is provided.) - Scriptable configuration and control through a custom wayland protocol and
separate
riverctlbinary implementing it.
Building
On cloning the repository, you must init and update the submodules as well with e.g.
git submodule update --init
To compile river first ensure that you have the following dependencies installed:
- zig 0.7.1
- wayland
- wayland-protocols
- wlroots 0.13.0
- xkbcommon
- libevdev
- pixman
- pkg-config
- scdoc (optional, but required for man page generation)
Note: NixOS users may refer to the Building on NixOS wiki page
Then run, for example:
zig build -Drelease-safe --prefix /usr install
To enable experimental Xwayland support pass the -Dxwayland option as well.
Usage
River can either be run nested in an X11/wayland session or directly from a tty using KMS/DRM.
On startup river will look for and run an executable file at one of the following locations, checked in the order listed:
$XDG_CONFIG_HOME/river/init$HOME/.config/river/init/etc/river/init
Usually this executable init file will be a shell script invoking riverctl to create mappings and preform other configuration.
An example init script with sane defaults is provided here
in the example directory and installed to /etc/river/init.
For complete documentation see the river(1), riverctl(1), and
rivertile(1) man pages.
Development
If you are interested in the development of river, please join us at #river on freenode. You should also read CONTRIBUTING.md if you intend to submit patches.
Licensing
river is released under the GNU General Public License version 3, or (at your option) any later version.
The protocols in the protocol directory are released under various licenses by
various parties. You should refer to the copyright block of each protocol for
the licensing information. The protocols prefixed with river and developed by
this project are released under the ISC license (as stated in their copyright
blocks).