| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A true "default" config doesn't make sense for river. Everyone who uses
river seriously will customize their init script. Futhermore, the
current behavior of embedding the install path of the default system
config in the river binary is complex and prone to breaking.
|
|
|
|
|
|
|
|
On output change, if the cursor is not already on the newly focused
output, it will now be warped to its center. The check is necessary,
since focusing outputs with the pointer will be implemented in
the future.
|
|
List based output operations are tedious for complex output layouts.
|
|
|
|
|
|
|
|
|
|
send-layout-value → set-layout-value
|
|
|
|
|
|
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 implements the changes to the river-layout protocol proposed
in the previous commit removing river-options.
|
|
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.
|
|
- Replace the layout option with new default-layout and output-layout
commands.
- Remove the ability to get/set the output title entirely.
|
|
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 is more convenient for interactive usage and makes using the same
bindings across multiple outputs easy.
|
|
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>
|
|
To make this cleaner, introduce some arg-parsing infrastructure that
will useful when porting riverctl to river-control-v2 in the future as
well.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
"tagmask" is a misleading term as the arguments are used much more like
a set of tags than a mask.
|
|
|
|
This unifies the style of the man page source files. Most noticable are
the now consistent line endings at 80 chars (assuming a tabwidth of 8).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This mode is automatically entered when the screen is locked.
|
|
This is more userfriendly than the empty string approach.
|
|
|
|
|
|
|
|
|
|
|
|
This command takes a mode, modifiers, button/event name, and pointer
action as arguments. It stores these in the config data structure.
The currently available pointer actions are move-view and resize-view,
which replace the previously hard-coded functionality.
Closing the hovered view with middle click has temorarily been removed
until it is decided if we wish to make this another special pointer
action or perhaps allow running any arbitrary command (which would of
course include close).
|
|
|
|
The set-option command got removed but was still present in SYNOPSIS,
which confused me. It is not the first time, we forgot to update it.
|
