| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Try to fix -h and -version. Remove seemingly superfluous -x everywhere,
only use one -f. Use -o for options. Update input devices listing.
Deduplicate some args. Try to do better for rule-add and rule-del.
|
|
|
|
Input name with ':' in it were not suggested entirely.
|
|
- Fix some completions that never really worked correctly, e.g `riverctl
input` didn't take the input name into account. Same with rule that
didn't take into account glob.
- Add a lot of documentation to help people adding new commands.
- Add new rule-[add|del] order.
- `riverctl input` now autocomplete input name from `riverctl
list-inputs`
|
|
Previous order was (action, conditions, action argument), current is
(conditions, action, action argument). The old one was an expansion of
(action, conditions), which itself most likely came from the separate
<action>-filter-add commands. On the other hand, the new order keeps
action and its argument together and is in line with the logical flow
(check conditions, apply action).
On shell completions: only bash absolutely needed to be updated. fish
and zsh slightly misbehave regardless of the order.
|
|
|
|
|
|
This is a breaking change and replaces the previous
csd-filter-add/remove and float-filter-add/remove commands.
See the riverctl(1) man page for documentation on the new system.
|
|
|
|
Warp the cursor to the center of the focused view if the cursor is not
in the bounding box of that view already. This helps the user to keep
track of their cursor when they mostly use the keyboard and the cursor
becomes hidden most of the time, also helps trackpad/trackpoint users.
|
|
|
|
This reduces the impact of keyboard groups on the Keyboard.zig
implementation and otherwise improves consistency with patterns used
elsewhere in rivers code.
There are also two small changes to the riverctl interface:
- keyboard-group-add-keyboard is renamed to keyboard-group-add
- keyboard-group-remove is added to support removing keyboards from a
group.
|
|
|
|
This was removed a while back because it was buggy and I didn't know
of anyone using it. Since refactoring it is now trivial to implement
and I know of at least one person using it, so I don't mind reviving it.
|
|
e.g. `riverctl map -layout 0 normal Super Y spawn foot`
When this mapping is checked against a pressed key, layout 0 will be used to translate the pressed key instead of the currently active layout.
The number denotes to an index of the layouts set with
`XKB_DEFAULT_LAYOUT`.
|
|
|
|
|
|
|
|
This allows running a command on a laptop's lid being opened/closed
or a tablet's button/switch being pressed/toggled.
|
|
|
|
|
|
This is likely more clear than "layout client" to most users.
|
|
|
|
- add a new "urgent" border color
- add a new event to river-status-unstable-v1
Co-authored-by: Isaac Freund <ifreund@ifreund.xyz>
|
|
Repeating mappings are created using the -repeat option to the map
command:
% riverctl map normal $mod+Mod1 K -repeat move up 10
- repeating is only supported for key press (not -release) mappings
- unlike -release, -repeat does not create distinct mappings: mapping a
key with -repeat will replace an existing bare mapping and vice-versa
Resolves #306
|
|
|
|
|
|
This code is complex and increases maintenance burden but doesn't
add any functionality, only eye-candy.
Futhermore, neither I nor any of the core contributors use it.
There may be a place in river for such eye-candy down the line, in which
case this code could be revived. Currently river is early enough in its
development that our focus should be on core functionality instead.
|
|
|
|
focus-follows-cursor instead of focus-follow-cursor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This implements the changes to the river-layout protocol proposed
in the previous commit removing river-options.
|
|
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.
|
|
|
|
|
|
Options are now all global but may be overridden per-output. If an
output local value is requested but none has been set, the global value
is provided instead. This makes for much better ergonomics when
configuring layout related options in particular.
|
|
|
|
|
|
|
|
|
