When setting the geometry from content for floating windows, the
coordinates for borders are normally taken into account. However in the
case of a floating fullscreen window, we should not be doing this. Since
the content of the container takes the space of the entire output, this
causes the calculated borders to neccesarily be outside of the output.
This later causes a problem when sending surface entrance events since
in a multi-monitor setup, the border coordinates will overlap with
another output despite the surface not actually being on that output at
all. The fix is to just ignore border coordinates for a floating
fullscreen container since fullscreen, of course, does not actually have
any borders. Fixes#6080.
New warnings can be hard to notice in CI, since CI will just pass in
that case. Meson sometimes uses warnings for important mistakes, e.g.
invalid option.
Let's turn warnings into errors so that we can spot these more easily.
get_current_time_msec is only used in cursor.c, so we can move it in and
make it static. This is primarily intended to avoid a symbol collision
with wlroots, which we unfortunately do not have a good solution for
yet.
This fixes the following scenario:
- Place a floating window so its border is right at the edge of the
screen
- Create a new split
- The border disappears
- Moving the window does not restore the border
Instead of disabling it for some workspace subcommands, this explicitly
calls it only in the 2 places it's actually needed: for switching to a
named or numbered workspace.
This extracts the code to a separate workspace_auto_back_and_forth
function.
It also removes the bool argument by adding an extra if statement at the call
site, and repurposes the no_auto_back_and_forth variable to
auto_back_and_forth for simpler understanding.
This forces no_auto_back_and_forth to true for `workspace
next_on_output` and `workspace prev_on_output` to keep parity with i3.
In i3, running next_on_output never changes focus to another output.
In Sway currently, with workspace_auto_back_and_forth set to yet,
running next_on_output on an output with only a single active workspace
will typically end up focussing the other output:
1. next_on_output focusses the current workspace, because it's the only
one
2. auto_back_and_forth focusses the last focussed workspace, because the
current workspace to focus is the current one. This will usually be on
the other monitor if the workspace there was last focussed.
Sway ignores SIGPIPE (by installing a SIG_IGN handler), in order to
“prevent IPC from crashing Sway”.
SIG_IGN handlers are the *only* signal handlers inherited in
sub-processes. As such, we should be a good citizen and restore the
SIGPIPE handler to its default handler.
Original bug report:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1806907.html
Sway ignores SIGPIPE (by installing a SIG_IGN handler), in order to
“prevent IPC from crashing Sway”.
SIG_IGN handlers are the *only* signal handlers inherited in
sub-processes. As such, we should be a good citizen and restore
the SIGPIPE handler to its default handler.
Original bug report:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1806907.html
Until now, swaybar did not have pango markup enabled by default, even if
the sway config had it on. This patch aims to mimic the i3 behavior, but
maintaining the functionality of the "pango_markup" sway config command.
