The following statusbar output is not considered by sway to be following
the swaybar-protocol:
{"version":1}[[{"full_text":"2.89","urgent":false}],
However this one is:
{"version":1}\n[[{"full_text":"2.89","urgent":false}],
Both outputs contain a header with the required values and an unfinished
array of objects with the required values, but the first one is showed
verbatim.
If the environment variable is not defined, getenv returns NULL.
Passing a NULL pointer to the "%s" format specifier is undefined
behavior. Even if some implementations output "(null)", an empty
string is nicer.
`!*rgba` tests if the first byte of rgba isn't `'\0'`.
`hex_to_rgba_hex` returns NULL if `parse_color` fails. There's a null
pointer dereference in that case. The intended behavior is `!rgba`.
The pointer `data` is cast to a more strictly aligned pointer type. To
prevent issues, the `data32` buffer is removed and its occurrences are
replaced with an offset from the `data` buffer.
If the mouse/cursor/pointer is near the edge of an output when a "move
position to pointer" command is run, then the floating container will be
constrained to fit inside the bounds of the output as much as possible.
This behavior matches what i3 does in this scenario. I also think it is
a better user experience.
Relates to #4906
The logic for the bounds check follows the implementation in i3: 7330778223/src/floating.c (L536)
Usually it should be enough to simply not grant a client's
minimize request, however some applications (Steam, fullscreen
games in Wine) don't wait for the compositor and minimize anyway,
getting them stuck in an unrecoverable state.
Restoring them immediately lead to heavy flickering when unfocused
on my test application (Earth Defense Force 5 via Steam), so it's
preferable to grant their request without actually minimizing and
then restoring them once they are in focus again.
`determine_bar_visibility` stops and starts the status command process according to the bar’s visibility. If the bar was hidden during teardown, teardown would stall while waiting for the stopped status command process to exit.
This resumes a stopped status command during teardown and allows, for example, sway to reload or quit without leaving a swaybar instance behind each time.
Fixes#5536.
CONT before TERM as requested in review.
The current version is prefixed by a "v" and therefore breaks the output
of "swaymsg -rt get_version" which is implemented trough
"sscanf(SWAY_VERSION, "%u.%u.%u", &major, &minor, &patch)".
The prefixed "v" was added in 8b2ff2f1, probably by accident.
On warping to a cursor hint, update the pointer position we track as
well, so that on the next pointer rebase we don't send an unexpected
synthetic motion event to clients.
Fixes#5405.
In case when slurp is used to select part of screen or a window, if user aborts
the selection, grimshot will capture the whole screen instead of exiting. This
is fixed with check for empty variable.
**Problem**
When I rename the workspace to something like "1:web",
`$mod+1` does not move to the "1:web" with the default config. This breaks
the expectation of i3 users.
**Cause**
The default Sway binding for `$mod+1` does not have the number
keyword:
```
bindsym $mod+1 workspace 1
```
Instead, the default Sway binding for `$mod+1` is
```
bindsym Mod1+1 workspace number $ws1
```
e6662df114
is the corresponding commit from i3.
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
As per the Wayland spec [1]:
> The icon surface is an optional (can be NULL) surface that provides an
> icon to be moved around with the cursor.
However, as of now Sway "start_drag" signal handler does not starts the
DND session unless a non-NULL drag icons is provided. This patch fixes
it by skipping handling of the drag icon if it is null.
Fixes#5509
[1] https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
This utilizes the newer Github issue templates. They allow for the user
to specify what type of issue they are submitting to allow for a more
specific issue template to be shown.
In addition to a hopefully easier to read/parse/follow bug report
template, this also include templates for enhancements and i3
compatibility. This also includes a link to the IRC under the section
title Questions.
For the three templates, the labels bug, enhancement, and i3-compat will
be automatically applied for the appropriate report to assist in
triaging.
Hopefully, this will result in less questions and issues for new window
management functionality on Github and allow for better quality issues
being submitted. At the very least, it allows us to outline our
stances for bugs, enhancements, and i3-compatibility in an easier to
read format.
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)
