In i3, the workspace_layout command does not affect the
workspace layout. Instead, new workspace level containers
are wrapped in the desired layout and the workspace layout
always defaults to the output orientation.
To query whether a container is sticky, checking `con->is_sticky` is
insufficient. `container_is_floating_or_child` must also return true;
this led to a lot of repetition.
This commit introduces `container_is_sticky[_or_child]` functions, and
switches all stickiness checks to use them. (Including ones where the
container is already known to be floating, for consistency.)
The function evacuate_sticky() was changed in commit 32788a93 to be used
by workspace_for_each_container() to make the code more readable. But I
overlooked that it is not safe to use workspace_for_each_container() to
remove container from a workspace. This commit restores the previous
implementation for evacuate_sticky().
Currently, when a floating container with a view is split and
children are added to it, the new views are rendered as tiled,
while the first view stays in floating style.
Here this is addressed by setting the view to tiled as soon
as the container is split, by duplicating the "view part" of
the logic in container_set_floating(..., false). Since the new
container of the view is no longer considered floating, it
makes sense to set the view to tiling at this point.
The view would have to be set back to floating if it was possible
to "unsplit" the container.
Sticky floating containers on an otherwise empty workspace can only be
evacuated if the new output has an active workspace. The noop output may
not have one and in that case we have to move the whole workspace to the
new output.
Currently, in view_autoconfigure, the only condition for show_border
is !view_is_only_visible. view_is_only_visible does not cross the
boundary between the workspace's tiling and floating lists and does not
differentiate between them.
The result is, that in a workspace with zero or more tiling containers
and a single floating container, the floating container will lose its
borders as soon as it is split, provided that a only one view is visible
within the floating container.
Fixed by adjusting the condition for show_borders.
Previously, we called output_disable prior to wlr_output_commit. This
mutates Sway's output state before the output commit actually succeeds.
This results in Sway's state getting out-of-sync with wlroots'.
An alternative fix [1] was to revert the changes made by output_disable
in case of failure. This is a little complicated. Instead, this patch
makes it so Sway's internal state is never changed before a successful
wlr_output commit.
We had two output flags: enabled and configured. However enabled was set
prior to the output becoming enabled, and was used to prevent the output
event handlers (specifically, the mode handler) from calling
apply_output_config again (infinite loop).
Rename enabled to enabling and use it exclusively for this purpose.
Rename configure to enabled, because that's what it really means.
[1]: https://github.com/swaywm/sway/pull/5521
Closes: https://github.com/swaywm/sway/issues/5483
xdg-shell doesn't allow clients to set the title to NULL, so we
shouldn't need to call wlr_foreign_toplevel_handle_v1_set_title with an
empty string to reset the old one.
Closes: https://github.com/swaywm/sway/issues/5488
If moving e.g. `T[app app]` into a new workspace with `workspace_layout
tabbed`, then post-move the tree in that workspace will be `T[T[app
app]]`. This still happens with horizontal or vertical workspace layout,
but is less visible since those containers have no decorations.
Fixes#5426.
It is not a part of the foreign-toplevel-management protocol to get the
class of a toplevel, only for getting the app_id.
For xwayland clients this is an issue because that means that you cannot
identify what application the toplevel refers to which is the point of
the app_id property.
By falling back to class when an app_id does not exist solves this problem.
Phoc also uses app_id and class interchangeably in their implementation
of foreign-toplevel-management, in fact they always do that and not only
for just this protocol.
c8d8a4c544/src/xwayland.c (L236)
During the execution of a resize transaction, the buffer associated
with a view's surface is saved and reused until the client acknowledges
the resulting configure event.
However, only one the main buffer of the main surface was stored and
rendered, meaning that subsurfaces disappear during resize.
Iterate over all, store and render buffers from all surfaces in the view
to ensure that correct rendering is preserved.
This fixes bugs where a floating container would take input way past its
borders when its parent was fullscreen, since the call to
`tiling_container_at` in input/cursor.c's `node_at_coords` did not check
bounds.
Add a separate per-view shortcuts_inhibitor command that can be used
with criteria to override the per-seat defaults. This allows to e.g.
disable shortcuts inhibiting globally but enable it for specific,
known-good virtualization and remote desktop software or, alternatively,
to blacklist that one slightly broken piece of software that just
doesn't seem to get it right but insists on trying.
Add a flag to sway_view and handling logic in the input manager that
respects that flag if configured but falls back to per-seat config
otherwise. Add the actual command but with just enable and disable
subcommands since there's no value in duplicating the per-seat
activate/deactivate/toggle logic here. Split the inhibitor retrieval
helper in two so we can use the backend half in the command to retrieve
inhibitors for a specific surface and not just the currently focused
one. Extend the manual page with documentation of the command and
references to its per-seat sibling and usefulness with criteria.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
See issue #5228. Currently, WL_OUTPUT_SUBPIXEL_NONE is ignored and
CAIRO_ANTIALIAS_SUBPIXEL is still set. This commit checks if subpixel is
set to none and if so, calls set_antialias with CAIRO_ANTIALIAS_GRAY.
This mirrors the functionality in Mako's
[PR261](https://github.com/emersion/mako/pull/261)
In the case of multiple overlapping floating windows, this commit fixes an issue where the wrong window would be focused in response to a cursor if one of the windows came from a different output (overhanging).
If a subsurface is created for a surface that is associated with a
scratchpad hidden view, do not attempt to send an enter to it. The
subsurface is not on any output and since there is no workspace
associated with the view, attempting to get the output for the NULL
workspace will result in a SIGSEGV.
The output manager config is created when the output is created. It is
updated when the mode, transform, scale, or layout for the output
changes, as well as, when the output is destroyed.
Since the output->enabled property was not being set before calling
apply_output_config, the output event handlers were early returning and
never updating the output manager config when the output state was
committed.
This fixes the issue by setting output->enabled in apply_output_config
below the output disabling section. There are also a few other minor
changes that are required to function.
Additionally, this renames output_enable to output_configure to better
describe the recent changes.
The only output_enable caller is now apply_output_config. Stop calling
apply_output_config from output_enable to simplify the code and avoid
the back-and-forth between these two functions.
output_enable is now the symmetric of output_disable: it just marks the
output as enabled and performs bookkeeping (e.g. creating teh default
workspace). It is called from apply_output_config after the output
commit, so that it can read the current output state and act
accordingly.
This change also allows us to avoid an extraneous wlr_output_commit.
References: https://github.com/swaywm/sway/issues/4921
The container_at_tabbed and container_at_stacked container were checking
the bounds along the y-axis, but not the x-axis. This made it possible
to cause a segfault for specific resolution, horizontal gap, and
workspace children lengths. The issue is that child_index was -1 and was
resulting in a buffer underflow. Adding the x-axis bound checks for
early returns should prevent this from happening.
When a container was being made fullscreen and it is on the focused
workspace for a seat, focus was being set to the container. However,
when the container was on a non-focused workspace, the focus stack
wasn't being touched. When assigning a fullscreen container to a
workspace or moving a fullscreen container to a different workspace,
this would make it so the fullscreen container was never added to the
focus stack for the workspace thus preventing access to the workspace.
This adds the container to the top of the focus stack, behind the
container on the focused workspace.
If a view is mapped to a workspace using an assign, the pid should still
be removed from the pid mapping list. This prevents child processes from
matching against it and mapping a view to a likely undesired workspace.
When gaps are resized for lack of space the calculation could result in
a gap size of non-integer pixels. This would result in containers
located at non-integer pixels which would be subtly broken.
Because the layout code rounds down the dimensions of the windows
resizing would often be off by one pixel. The width/height fraction
would not exactly reflect the final computed width and so the resize
code would end up calculating things wrong.
To fix this first snap the container size fractions to the pixel grid
and only then do the resize. Also use round() instead of floor() during
layout to avoid a slightly too small width. This applies in two cases:
1. For the container we are actually resizing using floor() might result
in being 1px too small.
2. For the other containers it might result in resizing them down by 1px
and then if the container being resized is the last all those extra
pixels would make the resize too large.
Fixes#4391
Any descendant of a scratchpad container may be fullscreen so checking
to see if the top-level scratchpad container is fullscreen in
root_scratchpad_hide is not sufficient. This iterates through all
descendants of the scratchpad container
Showing a window in the scratchpad can move a visible scratchpad window
from another workspace to the current one. If the scratchpad window was
the last visible container in that workspace, the old workspace should
be destroyed.
