Default output configs were generated on reload to reset an output to
its default settings. The idea was that anything that was removed from
the config or changed at runtime and not in the config should be reset
on reload. Originally, they were created using the output name. Recently,
they were changed to use the output identifier. It turns out that there
are issues of shadowing with that solution as well. This should fix
those issues.
Instead of generating the default output configs on reload and storing
them in the output config list to merge on top of, they are now only
generated when retrieving the output config for an output during a
reload. This means that the default output configs are never stored
anywhere and just used as a base to merge unaltered user configs on top
of during a reload.
Starting with a blank output config, merges get applied in the following
order:
1. Default output config (only during a reload)
2. Wildcard config (only if neither output name or output identifier
exist)
3. Output name config
4. Output identifier config
This patch moves view_execute_criteria(view) below the fullscreen code.
Previously, if a view requested to be started in fullscreen, this was
done after execution of criteria and hence it was impossible to disable
fullscreen via criteria.
Fixes#3285
When there are outputs with mixed scales, it was possible for swaybar to
alter `block->separator_block_width` for an output with a higher scale,
and use the changed value for a lower scale output. This caused there to
be larger than normal separation between blocks on the lower scale
outputs. The issue is more obvious the larger the scale difference
between the highest scale output and the lowest scale output.
This fixes the issue by using a local variable that is originally set to
`block->separator_block_width` for rendering, but if it needs to be
increased, the local variable is the only thing touched.
When `block->urgent` is set, use the urgent colors. This matches i3bar's
behavior. Previously, swaybar just ignored the property.
This also adds in rendering for right borders, which was missing.
Changing the focus stack when destroying a container's node on a
non-visible workspace (on an non-focused output) incorrectly causes
the non-visible workspace to become visible. If the workspace is empty,
it will not be destroyed since it is now visible. Additionally since
there was no workspace::focus event, swaybar still shows the previous
workspace as focus-inactive. It also makes no sense to change visible
workspaces due to a container on a non-visible workspace being
destroyed.
Since the focus will either be set when switching to the non-visible
workspace or the workspace will be destroyed due to being empty, there
is no need to change the focus stack when destroying a container on a
non-visible workspace.
Determine the container/workspace a command is run on, each time when a
command of the command list will be run.
Previously the container/workspace was determined only once at the
beginning of command list execution, which led to wrong behaviour
because commands wouldn't take into account when a previous command
changed the focused container.
When generating default output configs to reset the outputs to their
default settings on reload, the output name was being used.
Additionally when determining the output config to apply, if there was
an output config with the output name, that was being used without
checking for an identifier config. This caused sway to completely ignore
the users specified output config.
To fix this issue, the following changes have been made:
1. Default output configs as created for the identifier now instead of
name. This actually makes more sense anyway since you could hotplug
multiple different outputs to the same port.
2. In get_output_config, which is only used to determine which output
config to apply, output configs for both the name and identifier are
queried. If both are found, a new output config is generated with the
identifier config merged on top of the name config. If just one is found,
a copy of that config is returned. This change also requires that the
result from get_output_config be freed after use to prevent memory
leaks, which required some minor changes to logic in
apply_output_config_to_outputs.
If a scratchpad container is hidden, it is still focusable using
criteria and should be shown. This fixes a segfault when attempting to
rebase the cursor since previously the scratchpad container would not be
on any output.
Changes the error result from CMD_INVALID to CMD_FAILURE, since
CMD_INVALID indicates an unknown command or parser error and neither
occurs where CMD_INVALID was used.
Since the output config is no longer applied before creating the default
workspace, the layout for default workspaces on an output may not be
correct. Due to the ordering of calls in output_enable being changed in
several bug fix PRs, this just fixes the layout after the call to
apply_output_config.
When adding a container to the scratchpad, it was possible for focus to
be removed from the seat. This occurred when a single child was moved
from it's parent to the scratchpad due to the focus_inactive for the
parent being NULL. If the focus_inactive for the parent is NULL, the
focus_inactive for the workspace should be focused.
Adds the bar subcommand `gaps <amount>|<horizontal> <vertical>|<top>
<right> <bottom> <left>` to set gaps for swaybar. Due to restrictions on
margins for a layer_surface, only the sides that are anchored to an edge
of the screen can have gaps. Since there is support for per-side outer
gaps for workspaces, those should be able to be used instead for the
last side.
In `i3 4.16`, `i3-msg` can be used with the message type `subscribe`
and has the ability to monitor for responses until killed. This adds
support for both to swaymsg.
If the JSON array of event types is malformed or contains an invalid
event, sway will send a response with `success` set to `false`. If
swaymsg sees this, it will not display the failure and exit.
If the `subscribe` event is successful, swaymsg will wait for the first
response and display that instead of the success message. If
`-m/--monitor` is given, swaymsg will continue monitor for responses
until killed or a malformed response is received.
For the `subscribe` event, the responses will always be printed as JSON.
If `-r/--raw` is given, the JSON will not be pretty printed, which may
be preferred when monitoring due to there being multiple responses.
Example: `swaymsg -t SUBSCRIBE -m "['window']"`
