After previous commits, swaybar bindsym statements would already accept
the new pseudo button names for swipe gestures. Also, sway itself would
not handle swipes when executed while the pointer was above a bar.
Add the necessary handling for three- and four-finger swipe pointer
gestures in swaybar. Cancel ongoing swipes when the pointer leaves the
bar as to not confuse successive swipes with focus changes inbetween
them. Add the pointer gestures protocol in client and server variants
to the meson build file to make the necessary definitions available.
Bind to the global interface on startup, instantiate a swipe gesture and
add a listener on seat setup as well as destroy it on seat shutdown.
Extend the sway-bar manual page as necessary.
Test-plan:
- add workspace switching to config like so:
bar bar-0 {
swaybar_command swaybar
bindsym release SWIPE_3_LEFT workspace prev_on_output
bindsym release SWIPE_4_RIGHT workspace next_on_output
bindsym --release SWIPE_3_LEFT exec yad --text foo
bindsym --release SWIPE_4_UP exec yad --text bar
}
- start sway and open two workspaces
- position pointer above a bar surface
- switch back and forth using horizontal three- and four-finger swipes,
observing that different finger counts are necessary per direction
- observe that the --release binding for left swipes is ignored because
there is an on-press binding already
- observe that the --release binding for upward swipes is honoured
because there is no on-press binding
- move pointer away from bar surface
- observe that switching by swipe no longer works
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Add description of pointer gesture binding configuration and behaviour
to the sway(5) manual page.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Swipe pointer gesture bindings added in an earlier commit would catch
swipes indiscriminately, ignoring the number of fingers used.
Add the necessary logic to distinguish three- from four-finger swipes.
Other finger counts cannot be bound to and are passed through to clients.
Continue to trivially map each dimension of a gesture to discrete pseudo
button codes considering that we're unlikely to take this much further
and would otherwise need to extend struct sway_binding to carry some
kind of button-specific internal data.
Test plan:
- add workspace switching to config like so:
bindsym --whole-window SWIPE_3_LEFT workspace prev_on_output
bindsym --whole-window SWIPE_4_RIGHT workspace next_on_output
- start sway and open two workspaces
- switch back and forth using horizontal three- and four-finger swipes,
observing that different finger counts are necessary per direction
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Passing of gesture events added in #4794 allows to use them in clients
but not in sway itself, for example to switch workspaces using
three-finger swipes.
Add support for binding four basic directional swipes to arbitrary sway
commands. Add the necessary handling to default seatops to execute them
at the beginning or end of a swipe gesture. This for now responds to all
swipes, ignoring the number of fingers used.
The former throws up the intrinsic conundrum that we can not know the
kind of swipe that's going to happen because it can change all through
its lifecylce. Therefore we can only execute bindings on release.
Test plan:
- add workspace switching to config like so:
bindsym --whole-window SWIPE_LEFT workspace prev_on_output
bindsym --whole-window SWIPE_RIGHT workspace next_on_output
- start sway and open two workspaces
- switch back and forth using horizontal three-finger swipes, observing
that vertical swipes won't
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Let swipe pointer gestures percolate through seat and default seatop
handlers so sway-internal handling can be added if desired. As a
side-effect this makes swipes count as user activity. There should be no
other functional changes.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Mouse bindings are handled alongside normal bindings. Remove the unused
separate data structure definition to avoid confusion.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Losing the precision resulted in wlr_cursor and wlr_seat::pointer_state
getting out of sync during pointer motion in seatop_down.
Since the difference was always under 1 px, it was practically
impossible to notice in normal use.
But because of being out of sync, cursor_rebase would always end up
incorrectly calling wlr_seat_pointer_notify_motion from
seatop_default_begin (on releasing mouse button) which broke cursor
locking.
See #5405Closes#4632
When emulating touch, the simulating_pointer_from_touch field is
set to true. It's switched back to false when a touch_up event is
received. However we need to ensure we always send a wl_pointer.frame
event following a group of other wl_pointer events.
Since a touch_frame event is always guaranteed to come after a group
of touch events, unset simulating_pointer_from_touch in the touch_frame
handler instead of the touch_up handler. Add a new field to know whether
the touch_frame handler should stop emulation.
If HOME environment variable is not set, sway fails startup with a
segmentation fault due to null pointer dereference.
Also check calloc return value and only perform the fallback code when
really needed.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Add a subcommand for `gaps` that allows to toggle gaps at
runtime. This functionality is part of i3-gaps since [1]
but is missing in sway.
[1] https://github.com/Airblader/i3/pull/264
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.
Deferred commands are only run once, during sway startup. This means
that deferring seat attachment based on whether we are reading the
config prevents devices from being reattached to the correct seat during
a config reload. Instead, only defer if the config is not yet active.
Fixes#6048.
