river-options: remove protocol

[ifreund]

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 simply add requests
and 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 request (riverctl)
2. receive set_foo request (river)
3. send set_foo event (river)
4. send layout_demand (river)

This requires much less back and forth between the server and clients
and is clearly much simpler.

Note: river-options is currently used for 2 core river features, setting
the active layout and setting the output title. These features are
planned to be moved to the

[ifreund]

I'm considering removing the set_foo requests from the layout manager and making them a normal river command instead. They would the become part of the revised river-control protocol which would allow them to participate in whatever solution I come up with for atomic batches of commands.

[ifreund]

My current plan for rivertile is to only expose main_location, main_count, and main_factor as runtime configurable options, view_padding and outer_padding will be set exclusively through command line arguments.

[ifreund]

I'm considering removing the set_foo requests from the layout manager and making them a normal river command instead. They would the become part of the revised river-control protocol which would allow them to participate in whatever solution I come up with for atomic batches of commands.

Just did this.

Additionally, I've realized that we need a convenient way to apply deltas to layout values for interactive usage. To this end, I've added mod_int_value and mod_fixed_value events. Since applying a delta to a string does not make sense, there is no mod_string_value event. Similarly since applying negative modifiers is useful and expected, a mod_uint_value taking a uint argument would be rather useless. Instead, let's just keep things simple and use ints for everything. This leaves us with the following new events on the river-layout object:

• set_int_value
• mod_int_value
• set_fixed_value
• mod_fixed_value
• set_string_value