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.
main is a better term to use here for several reasons:
1. It is more accurate: "master" implies that the designated views have
some kind of control over the other views, which is not the case. "main"
better expresses that the difference between the "main" view and others
is one of importance/focus.
2. It is a shorter word. 2 whole characters saved!
3. It reduces the chance of future development time being lost to
good-intentioned people complaining about usage of the word master as
has recently happened with regards to the default git branch name.
