Currently the spawn command takes any number of arguments and naively
joins them together with spaces before passing them as the single
argument of `/bin/sh -c`. This however produces unexpected results as
soon as shell quoting gets involved in the arguments passed to spawn.
For example, running
riverctl spawn foo "bar baz"
will execute `/bin/sh -c "foo bar baz"`, unexpectedly splitting bar and
baz into separate arguments. To avoid this confusion, make the spawn
command take only a single argument, forcing the user to quote properly
to spawn multi-argument commands.
- Remove advertise_view and advertise_done events. Using the information
provided by these for any purpose would make the layout far less
predictable. Futhermore, in the months this has been available for use,
to my knowledge nobody has actually used it for anything useful.
- Replace the set/mod layout value events with a single user_command
event. This simplifies the protocol and is more flexible for clients.
- Add a layout_name argument to the commit request. This name is an
arbitrary, user-facing string that might, for example, be displayed by a
status bar. This was present in early drafts of the protocol, but was
removed in favor of river-options. Since river-options itself has since
been removed and this feature is nice to have, re-add it.
- Rename main factor to main ratio in rivertile. The "factor" name was
just legacy from dwm, "ratio" is much more accurate.
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.
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.
Replace the current layout mechanism based on passing args to a child
process and parsing it's stdout with a new wayland protocol. This much
more robust and allows for more featureful layout generators.
Co-authored-by: Isaac Freund <ifreund@ifreund.xyz>
