Xwayland views are aware of their coordinates, so validating transaction
completions should take into account the reported coordinates of the
view. Prior to this commit they didn't, and matching dimensions would
suffice to validate the transaction.
Also introduced `transaction_notify_view_ready_immediately` to support
the fix from d0f7e0f without jumping through hoops to figure out the
geometry of an `xdg_shell` view.
Sway logical coordinates are doubles, but they get truncated to integers
when sent to Xwayland through `xcb_configure_window`. X11 apps will not
respond to duplicate configure requests (from their truncated point of
view) and cause transactions to time out.
Fixes#5035.
Prior to this commit, having a layout like T[app1 V[app2]], focusing
app2, and then doing `move left` would result in T[app2 app1]. Now, the
resulting layout is T[app1 app2], which matches i3 behavior.
`container_flatten` updates `container->parent`, meaning that the
existing check would never be true.
i3 shows indicators for the workspace-level pseudo-split, but Sway does
not, as of b977c02. This commit replaces the floating container check
with a call to `container_is_floating`, which has some more robust
checks in place.
Fixes#5699.
We can't arm the timer during cursor creation since the config may not
be ready yet. Instead arm the timer while applying the input
configuration, by this time the configuration has been parsed and we can
arm the hide timer.
Fixes#5686
According to the wayland docs, wayland timers are disarmed on creation.
This leads to the cursor not being hidden if there is no activity after
creation, since the timer is armed on activity, but not at creation.
Arm the timer after creation to ensure the cursor is hidden even if
there is no cursor activity after creation.
Fixes#5684
Reset the event source after unhiding the cursor, to ensure that the
timeout starts after showing the cursor. Also remove the open coded
variant in seat_consider_warp_to_focus().
Fixes#5679
My primary issue was IntelliJ IDEA's code suggestion pop-up not returning focus
to the active editing window.
I have spent some time looking at the changes of @Xyene (#5398) and
@RyanDwyer (#2103). I think my proposed change maintains the status
quo for the most part whilst fixing my focus issue.
I have verified that @Xyene's fix for IntelliJ sub-menus still works.
I have done basic testing which consists of:
- Chrome
- IntelliJ IDEA 2020.2.1
- VSCode
- Alacritty
It seems to hold up. I at least didn't see any obvious errors.
Relates to #3007
This changes it so all libinput config options are set on any device
that supports it. Previously, only a subset of libinput config options
were being considered depending on the input type. Instead of trying to
guess which properties the device may support, attempt to set any
configured property regardless of the device type. All of the functions
already have early returns in them for when the device does not actually
support the property. This brings the configuration side inline with
describe_libinput_device for the IPC side. This change was prompted
by a tablet tool showing the calibration matrix property in the IPC
message, but not being able to actually change it since that property
was only being considered for the touch input type.
Instead of listening to both transform and scale events, we can listen
to the commit event and use the new wlr_output_event_commit struct to
decide what to do.
This de-duplicates some of the work we were doing twice when an output
was re-configured.
Depends on [1].
[1]: https://github.com/swaywm/wlroots/pull/2315
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.
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.
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>
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)
wlr_drag installs grabs for the full duration of the drag, leading to
the drag target not being focused when the drag ends. This leads to
unexpected focus behavior, especially for the keyboard which requires
toggling focus away and back to set.
We can only fix the focus once the grabs are released, so refocus the
seat when the wlr_drag destroy event is received.
Closes: https://github.com/swaywm/sway/issues/5116
If a client commits a new size on its own, we create a transaction for
the resize like any other. However, this involves sending a configure
and waiting for the ack, and wlroots will not send configure events when
there has been no change. This leads to transactions timing out.
Instead, just mark the view ready immediately by size when the client
is already ready, so that we avoid waiting for an ack that will never
come.
Closes: https://github.com/swaywm/sway/issues/5490
Prior to this commit, a tablet device could trigger mouse button down
bindings if the pen was pressed on a surface that didn't bind tablet
handlers -- but it wouldn't if the surface did bind tablet handlers.
We should expose consistent behavior to users so that they don't have to
care about emulated vs. non-emulated input, so stop triggering bindings
for any non-pointer devices.
Previously, a tablet or touch device could report activity as a pointer
device if it went through pointer emulation. This commit refactors idle
sources to be consistently reported based on the type of the device that
generated an input event, and now how that input event is being
processed.
Prior to this commit, a tablet device could trigger mouse button down
bindings if the pen was pressed on a surface that didn't bind tablet
handlers -- but it wouldn't if the surface did bind tablet handlers.
We should expose consistent behavior to users so that they don't have to
care about emulated vs. non-emulated input, so stop triggering bindings
for any non-pointer devices.
This commit makes tablet input more usable when `focus_follows_mouse` is
set to `no`.
Previously, tapping down on surfaces that bound tablet input would not
switch focus, whereas tapping on surfaces that didn't (and hence went
through pointer emulation) did.
This adds support for wlr_keyboard_group's enter and leave events. The
enter event just updates the keyboard's state. The leave event updates
the keyboard's state and if the surface was notified of a press event
for any of the keycodes, it is refocused so that it can pick up the
current keyboard state without triggering any keybinds.
If a resize is triggered on a tabbed or stacked container, change focus
to the tab which already had inactive focus, rather than to the tab
whose border was clicked -- otherwise, we'd change the active tab when
the user probably just wanted to resize.
This commit makes `get_current_time_msec` correctly return milliseconds
as opposed to microseconds. It also considers the value of `tv_sec`, so
we don't lose occasionally go back in time by one second. Finally, the
function is moved into `util.c` so that it can be reused elsewhere
without having to consider these pitfalls.
We are not allowed to do what we did in #5222 and pass a `NULL` surface
wlr_seat_pointer_notify_enter(), and it's causing crashes when an
xdg-shell popup is active (see #5294 and swaywm/wlroots#2161).
Instead, solve #5220 using the new wlroots API introduced in
swaywm/wlroots#2217.
This commit moves tool tip event generation into seatops. In doing so,
some corner cases where we'd erroneously (but likely harmlessly)
generate both tablet and pointer events simultaneously are eliminated.
The centering logic needs to take borders, titlebars and CSDs into
account. Instead of using the main surface geometry, use the container
and view geometry, which account for this.
During the execution of a resize transaction, the buffer associated
with a view's surface is saved and reused until the client acknowledges
the resulting configure event.
However, only one the main buffer of the main surface was stored and
rendered, meaning that subsurfaces disappear during resize.
Iterate over all, store and render buffers from all surfaces in the view
to ensure that correct rendering is preserved.
This is necessary because some applications (e.g. Jetbrains IDEs)
represent their multi-level menus as unmanaged surfaces, and when
closing a submenu, the main menu should get input focus.
Closes#5347.
This fixes bugs where a floating container would take input way past its
borders when its parent was fullscreen, since the call to
`tiling_container_at` in input/cursor.c's `node_at_coords` did not check
bounds.
This emits frame events for the seat_cmd_cursor subcommands. The
wl_pointer frame event are required to notify clients when to process
the events. It will now be emitted after cursor movement, button press,
button release, and axis events.
This is a tiny cleanup commit that renames `simulated_tool_tip_down` to
`simulating_pointer_from_tool_tip`, making it match
`simulating_pointer_from_touch`.
This is a better name since it makes it clear that it's the *pointer*
that's being simulated, not the tool tip.
After swaywm/wlroots#2023, #4996 inverted configuration transformations.
For consistency, we should undo (double-apply) the inversion when
communicating via IPC.
Closes#5356.
The spec has this to say about sending events on confine creation:
Whenever the confinement is activated, it is guaranteed that the
surface the pointer is confined to will already have received pointer
focus and that the pointer will be within the region passed to the
request creating this object.
...and on region update:
If warped, a wl_pointer.motion event will be emitted, but no
wp_relative_pointer.relative_motion event.
Prior to this patch, sway did neither, and updated the hardware cursor
position without notifying the underlying surface until the next motion
event. This led to inconsistent results, especially in applications that
draw their own software cursor.
Tudor Brindus
Ronan Pigott
Tarmack
Tobias Langendorf
David96
John Mako
Rouven Czerwinski
Geoffrey Casper
BrassyPanache
Brian Ashworth
Simon Ser
Konstantin Pospelov
Rex Hackbro
Antonin Décimo
Thayne McCombs
Nils Schulte
Andri Yngvason
Nick Diego Yamane
wb9688
Johan Bjäreholt
Isaac Freund
Kenny Levinsen
Drew DeVault
Jason Nader
Thomas Hebb
Kalyan Sriram
Damien Tardy-Panis