Add support for command line arguments to set default values for the
various options of rivertile, bringing us back to rough feature parity
with before the commit removing the river-options 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.
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.
Run the init command in a new process group and send SIGTERM to the
entire group on exit. Without doing this, only the sh invocation used
for the `sh -c` would receive SIGTERM.
This is particularly useful when starting a per-session server manager
as the init command.
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>
This reverts commit c457b12cf3.
This attempted workaround seems to work fine if the output commit only
fails with EBUSY, but enters an infinite loop otherwise.
It kinda shows that this was the first protocol I ever implemented
server-side:
- Use client as well as ID for keys in the hashmap as IDs might
(and will) be the same between clients.
- Clear saved args after running a command.
This change is made in the interest of allowing users to simply re-run
their init script at runtime without errors. Making this an error
doesn't really gain us anything.
The ergonomics of remapping keys are currently quite bad as unmap
must first be called for every mapping before defining a new one.
Any benefit that might be gained by the current strictness of map/
map-pointer is outweighed by this fact.
In a similar spirit, silently ignore unmapping a non-existent mapping.
This is important to use instead of direct access as clients are not
strictly required to set a geometry, in which caese the dimensions
of the wl_surface are used instead.
Passing an empty string as the value argument for riverctl set-option or
declare-option will set the value to null. The riverctl get-option
command produces no output for both null and empty string values.
This is not perfect as it is unable to distinguish between null and
empty strings through the riverctl CLI. I don't see a better alternative
here however. Forbidding null strings in the river-options protocol
would be one solution, however null strings are useful and more pleasant
to use from code despite being problematic on the CLI.
Outputs now have a default option, "output_title". If this changes, the
outputs title is set to the option value. This title is currently only
relevant when run nested in a wayland/X11 session.
Co-authored-by: Isaac Freund <ifreund@ifreund.xyz>
This is done when river's internal Output struct is destroyed, not when
the advertised wl_output global is removed. This means that options will
persist when an output is disabled and re-enabled.
This allows the compositor to restrict options to a certain set of
values, which can be desirable if the options affect compositor
behavior.
This was always the intended behavior of the protocol, but now it is
explicitly stated.
