Fork of river (Wayland compositor, https://codeberg.org/river/river)

Go to file

tiosgz 7f30c655c7 Cursor: keep focus_follows_cursor_target updated This goes as close as possible to the behavior before this state was introduced (keeping the improvement which needed it, `931405ab`), fixing various mis-interactions of keyboard and focus_follows_cursor focus changes. The following text is irrelevant to restoring correct basic FFC behavior and talks about less common scenarios with regards to FFC clashing with views' input region beyond their geometry, continuing the work done in `931405ab`. Scenario 1: the cursor traveling along a view's border in a "dead zone", never initiating a focus change. If the focused view has an extended input region, that area has some functionality (such as client-initiated resizing); therefore it should be respected and even if another view's geometry is also under the cursor, focus shouldn't change. In case of unfocused views, it is a matter of consistency with the focused-view case. This outcome is also easier to implement, as it doesn't require any additional code. Scenario 2: clicking such a dead zone, i.e. extended input region (of an unfocused view). In question is not whether to focus the view (yes), but whether the focus_follows_cursor_target should be set to the view as well. Only one case seems relevant to me here, which is when ffc_target is another view whose geometry is under the cursor, but covered by this newly-focused view's input region. The most likely action following the click is resizing the newly-focused view, where a touchpad or faulty mouse could make the cursor move a bit farther after the button has been released. I believe that ffc_target shouldn't have been updated, in order to now prevent focus from skipping away. (Another variant is me, wondering why the wrong view got focused and trying to focus the right one using FFC. In that case, however, one could ask if it's river that misbehaves and whether the application is really well-integrated into the user's desktop when it provides a feature they don't desire.)		2023-09-05 12:25:42 +02:00
.builds	river: rework core data structures & transactions	2023-02-28 18:28:17 +01:00
common	river: add rules system	2023-03-12 16:44:19 +01:00
completions	river: focus-view and swap by spatial direction	2023-07-09 23:20:06 +02:00
contrib	contrib: mention default-layout command in FAQ	2022-10-26 10:29:23 +02:00
deps	xdg-decoration: clean up implementation	2023-03-10 18:49:30 +01:00
doc	river: focus-view and swap by spatial direction	2023-07-09 23:20:06 +02:00
example	example/init: update for rules system	2023-03-12 17:26:44 +01:00
protocol	river-control: mark callback events as destructors	2022-12-31 23:22:47 +01:00
river	Cursor: keep focus_follows_cursor_target updated	2023-09-05 12:25:42 +02:00
riverctl	riverctl: Add error messages for failed connections	2023-06-05 20:01:27 +02:00
rivertile	flags: further cleanup after Zig 0.10	2023-01-08 17:01:14 +01:00
.editorconfig	editorconfig: fix typo	2023-05-02 13:37:37 +00:00
.gitignore	code: update to zig 0.8.0	2021-06-05 17:29:58 +00:00
.gitmodules	code: switch to custom wlroots/libwayland bindings	2020-12-13 22:53:33 +01:00
build.zig	river: add rules system	2023-03-12 16:44:19 +01:00
CONTRIBUTING.md	docs: fix typo in readme	2022-11-17 14:58:08 +01:00
LICENSE	Relicense to GPL-3.0-or-later	2020-05-02 19:21:10 +02:00
PACKAGING.md	docs: add note on example init file to PACKAGING.md	2022-05-22 19:17:14 +02:00
README.md	docs: remove repology badge from readme	2023-02-03 18:27:38 +01:00

README.md

river

River is a dynamic tiling Wayland compositor with flexible runtime configuration.

Install from your package manager — Join us at #river on irc.libera.chat — Read our man pages and wiki

Note: river is currently early in development. Expect breaking changes and missing features. Bugs should however be rare at this point, if you run into one don't hesitate to open an issue

Design goals

Simple and predictable behavior, river should be easy to use and have a low cognitive load.
Window management based on a stack of views and tags.
Dynamic layouts generated by external, user-written executables. A default rivertile layout generator is provided.
Scriptable configuration and control through a custom Wayland protocol and separate riverctl binary 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. The "development" versions are required if applicable to your distribution.

zig 0.10
wayland
wayland-protocols
wlroots 0.16
xkbcommon
libevdev
pixman
pkg-config
scdoc (optional, but required for man page generation)

Then run, for example:

zig build -Drelease-safe --prefix ~/.local install

To enable experimental Xwayland support pass the -Dxwayland option as well.

If you are packaging river for distribution, see also PACKAGING.md.

Usage

River can either be run nested in an X11/Wayland session or directly from a tty using KMS/DRM. Simply run the river command.

On startup river will run an executable file at $XDG_CONFIG_HOME/river/init if such an executable exists. If $XDG_CONFIG_HOME is not set, ~/.config/river/init will be used instead.

Usually this executable is a shell script invoking riverctl(1) to create mappings, start programs such as a layout generator or status bar, and perform other configuration.

An example init script with sane defaults is provided here in the example directory.

For complete documentation see the river(1), riverctl(1), and rivertile(1) man pages.

Licensing

River is released under the GNU General Public License v3.0 only.

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).