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