Sway has two knobs to control idling:
- seat idle_inhibit: when the seat is active (ie. not idle), this
extends the active state. When the seat is idle, this is
ignored.
- seat idle_wake: when the seat is idle, this wakes up the seat.
When the seat is active, this is ignored.
The motivation for the deprecation is two-fold:
- The concept of "seat idle state" is ill-defined. Each idle-notify-v1
client will pass a different idle timeout. With the old logic, a
seat was declared idle if and only if all idle-notify-v1 timeouts have
expired. However, if only a portion of the timeouts have expired,
then some clients would wake up, and the rest would stay active.
This is inconsistent with the definition of idle_inhibit/idle_wake:
idle_inhibit was used for clients which are waking up.
- It never worked properly with the new idle-notify-v1 protocol
and no-one noticed. Only the legacy KDE idle protocol is taken
into account, but that protocol is not used anymore.
This makes the behavior of floating containers more consistent with i3.
The coordinates of the container are scaled when the size of the
workspace it is on changes or when the container is moved
between workspaces on different outputs.
For scratchpad containers, add a new state that preserves the dimensions
of the last output the window appeared on. This is necessary because
after a container is hidden in the scratchpad, we expect it to be in the
same relative position on the output when it reappears. We can't just
use the container's attached workspace because that workspace's
dimensions might have been changed or the workspace as a whole could
have been destroyed.
This function was already declared in container.h but defined in
commands/swap.c for some unknown reason. Everything in commands/ assumes
the handler context has been set appropriately by the command preludes
but this function snuck its way into seatop_* which doesn't set anything
in the handler context.
The fact that the seatop drag actions manipulate the focus without
custody of the seat means they are definitely very broken in multiseat.
efd83cb8 added the rotation_angle command but it didn't insert it in
the proper place in the list, so the repeat_delay and repeat_rate
commands became unusable.
See: https://github.com/swaywm/sway/issues/4511
Adds a bool config option `primary_selection`, which explicitly
enables/disables the primary selection clipboard. Defaults to enabled.
This is implemented as a launch-only option which enables or disables the creation of the
`zwp_primary_selection_device_manager_v1` global.
Co-authored-by: Tilde Rose <t1lde@protonmail.com>
This removes the need to rename the pid_workspaces when a workspace
is renamed.
It also opens the possibility of tracking other node types. Tracking
containers would allow application to be placed correctly in the
container tree even if the user has moved their focus elsewhere since
it was launched.
Support the new dwtp (disable while trackpointing) option introduced in
libinput 1.21, allowing users to control whether the trackpoint (like
those in Thinkpads, but not only) should be disabled while using the
keyboard/touchpad.
See: https://gitlab.freedesktop.org/libinput/libinput/-/issues/731
Use pango to parse font configuration early, and reject the command as
invalid if the value is invalid for pango. Since we're already parsing
the font into a `PangoFontDescription`, keep that instance around and
avoid re-parsing the font each time we render text.
Fixes: https://github.com/swaywm/sway/issues/6805
If the input device is quoted, which is common when using variables in the
config file, those quotes must be ignored here, or the input device will be
ignored.
Fixes#7029.
The "dpms" command refers to VESA Display Power Management
Signaling, a deprecated standard. It's superseded by VESA DPM.
Instead of tying out command name to a particular standard, use the
neutral term "power".
sway-bar(5) says:
> For compatibility with i3, bar mode <mode> [<bar-id>] syntax is
> supported along with the sway only bar <bar-id> mode <mode> syntax.
while the actual behavior is that `bar_cmd_mode` ignores already
selected `config->current_bar` and applies the change to all the
configured bars.
This makes it possible to hint to the renderer and backends how many
bits per channel the buffers that the compositor draws windows onto
should have. Renderers and backends may deviate from this if they
do not support the formats with higher bit depth.