Commit Graph

14 Commits

Author SHA1 Message Date
Keith Hubbard
2bdf9e20a5
command: support repeating keyboard mappings
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
2021-08-15 14:49:11 +02:00
novakane
879046ef83 completions: Remove strict in focus-follows-cursor 2021-07-29 17:19:06 +00:00
novakane
22251fa7ed
completions: Update for river-layout-v3 2021-07-20 10:48:48 +02:00
Isaac Freund
96e1082156 river: remove opacity command
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.
2021-07-20 08:47:02 +00:00
Viktor Nagy
28fc8792d7 river: add focus-previous-tags command 2021-07-15 12:00:22 +00:00
Isaac Freund
df492f83e6 completions: add set-cursor-warp for zsh/fish 2021-06-26 19:03:49 +02:00
FollieHiyuki
12c12c4b6c completions: add fish completion for input command 2021-06-16 09:59:37 -07:00
novakane
2e7c1dbe6a config: make attach-mode global 2021-06-08 18:26:36 +00:00
Isaac Freund
e80b883a47 river-layout: update to v2
This implements the changes to the river-layout protocol proposed
in the previous commit removing river-options.
2021-04-27 00:10:20 +02:00
Isaac Freund
871fc7c8de river-options: remove protocol
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.
2021-04-27 00:10:20 +02:00
Isaac Freund
891eb38b33
completions: delete more removed commands 2021-04-21 16:51:53 +02:00
skuzzymiglet
967b274c01 completions: Remove completions for removed subcommand "layout" 2021-04-21 16:47:27 +02:00
Isaac Freund
d08032d685 river-options: rework, bump to v2
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.
2021-04-20 18:27:03 +02:00
FollieHiyuki
8627a2feff riverctl: add fish completion 2021-03-16 17:38:21 +01:00