Age | Commit message (Collapse) | Author |
|
|
|
For certain applications (e.g. JetBrains) the parent window controls
input. We need to adhere to the ICCCM input focus specification to
properly handle these cases.
Relates to swaywm/wlroots#2604
|
|
This happens when Sway is not installed on the system, so there's no
default config in /etc.
|
|
|
|
|
|
|
|
Swap the "surface" part for consistency with wlroots' naming.
|
|
Instead of calling wlr_xdg_surface_for_each_popup and then
wlr_surface_for_each_surface, use the new for_each_popup_surface helper
introduced in [1] that does it in one go.
[1]: https://github.com/swaywm/wlroots/pull/2609
|
|
This ensures we don't swap two atoms by mistake.
|
|
Also remove the AUTHORS section from swaybar-protocol(7), for
consistency with the rest of the man pages.
|
|
|
|
This fixes a dangling reference which causes a use-after-free.
|
|
This fixes use-after-free when seat_destroy() has been called.
|
|
This fixes a crash that happens when input_method_new or text_method_new
events are emitted after the seat has been freed.
|
|
It's removed upstream [1].
[1]: https://github.com/swaywm/wlroots/pull/2561
|
|
|
|
Changes workspace prev|next commands to visit each numbered or named
workspace first before considering workspace from the other category
|
|
|
|
|
|
workspace_squash is container_flatten in the reverse
direction. Instead of eliminating redundant splits that are
parents of the target container, it eliminates pairs of
redundant H/V splits that are children of the workspace.
Splits are redundant if a con and its grandchild have the
same layout, and the immediate child has the opposite split.
For example, layouts are transformed like:
H[V[H[app1 app2]] app3] -> H[app1 app2 app3]
i3 uses this operation to simplify the tree after moving
heavily nested containers to a higher level in the tree via
an orthogonal move.
|
|
This changes the move command to better match i3
behavior after the layout changes.
workspace_rejigger handled the case where containers would
escape their workspace in an orthogonal move by changing
the layout to accomodate them, but this case is now handled
within the loop.
|
|
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.
|
|
This is in preparation for changing the workspace_layout
command to work like it does in i3.
This reverts commit b4a75a1ab2a72842830aeea37733311f85e6f660.
|
|
Some comparisons of current Sway versus i3 behavior:
1) T[T[T[app]]] + move left
* Sway: T[app]
* i3: T[T[app]]
2) H[V[H[V[app]]]] + move left
* Sway: H[app]
* i3: H[V[app]]
After this commit, Sway behavior matches i3. The intermediate states
are now:
T[T[T[app]]] -> T[T[app T[]]] -> T[T[app]]
H[V[H[V[app]]]] -> H[V[app H[V[]]]] -> H[V[app]]
|
|
In i3 the layout command on a workspace affects the workspace layout
only on empty workspaces. Otherwise children are placed in a new
container with the desired layout to preserve the workspace layout.
|
|
In i3 splits are ineffective on singleton H/V containers,
and the command is interpreted to affect the parent layout
instead.
|
|
This avoids some log spam.
Eventually when we wire up the atomic test commit this will take care of
the other log spam referenced below.
References: https://github.com/swaywm/sway/pull/5010
References: https://github.com/swaywm/wlroots/issues/2181
Closes: https://github.com/swaywm/wlroots/issues/2532
|
|
Instead of letting wlroots print messages to stdout, route debugging
messages into Sway's logging functions. This allows a more consistent
output (e.g. if Sway or wlroots changes its output style, they don't get
out-of-sync).
I also added a [wlr] prefix to wlroots messages, not yet sure it's a
good thing.
|
|
|
|
|
|
Damage subsurfaces created by layer surfaces on map, unmap and
commit. This fixes the flicker of Gtk Popovers.
Fixes #5617
|
|
Fixes #5847.
|
|
For each following combinations of criteria & command below, the command would
crash sway without the fix.
It's particular about the __focused__ criteria, where the view matches part of
the criteria but not the focused app, leading to a failure when calling
`strcmp` with NULL.
"xterm" is a non-wayland app (X11) and "kitty" is. Both are terminals.
# "class" is specific to X11
# The view is X11 (xterm) leading to the criteria checking for the
# focused app's class, leading to a crash
for_window [class="__focused__"] floating enable
exec kitty -e xterm
# Similarly, crash as the focused app (xterm) has no app_id when the view has one
for_window [app_id="__focused__"] floating enable
exec xterm -e kitty
# If the view has a title but not the focused app: NULL title will crash criteria checking
for_window [title="__focused__"] floating enable
exec xterm -title "" -e xterm
|
|
Currently, when sway sends a configure with some geometry and the
client responds with a different geometry in a commit that acks that
configure, sway ignores the new size. Sway applies the surface
geometry it had requested to the container, not what was actually
committed, in the following transaction.
This change allows any client commit to change its surface geometry,
even if it is a response to a configure event.
|
|
|
|
|
|
The keyboard group's effective keyboard layout was never being changed
due to a condition that incorrectly preventing it from being performed.
The IPC event that follows the change was correctly being prevented.
|
|
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.)
|
|
References: https://github.com/swaywm/wlroots/pull/2470
|
|
References: https://github.com/swaywm/wlroots/pull/2446
|
|
Previously, `find_edge` on a single fullscreen view would occasionally
return an edge rather than `WLR_EDGE_NONE`. This would trigger entry
into `seatop_resize_tiling`, which doesn't have meaning for a fullscreen
view.
The result was that the fullscreen container hitbox was considered to be
that of where it'd be if it were tiling, so most clicks would not go
through.
Fixes #5792.
|
|
When scrolling on a tabbed/stacked container, i3 focuses its
inactive-focused focused child. Sway does the same, but then resets the
focus to whatever was focused previously.
Ref https://github.com/i3/i3/blob/e5992eed163179f5cd2715c2c212d3d757f04b31/src/click.c#L207-L219
|
|
This commit switches focusing behavior to force a warp when executing
`focus mode_toggle`.
Fixes #5772.
|
|
Straightforward cleanup, they haven't been used for a while.
|
|
Add an option for the `hide_cursor` command to hide the cursor when
typing, i.e. whenever a key is pressed.
|
|
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.
|
|
Reset the workspace layout to the output's default only if the workspace
is actually attached to an output.
Fixes #5762
|