daaec72ac0 ("desktop/xwayland: restack surface upon activation")
has updated Sway for wlroots commit bfc69decdd04 ("xwm: do not
restack surfaces on activation"). However, it unconditionally
restacks the window above all other windows even if marking the
window as inactive.
Closes: https://github.com/swaywm/sway/issues/7974
Instead of doing this roundabout thing where we get the surface from the
view, let's instead get it from the `wlr_surface_state` that we already
track in `handle_commit`. This makes the NULL state impossible which is
what the old `get_geometry` is checking for and generally cleans
things up a little bit.
Also don't check if the geometry x/y changed, those will always
be 0 for xwayland.
Currently, a floating window that's been fullscreened can send us
xdg_toplevel::move, and we'll enter seatop_move_floating, which lets us
drag the surface around while it's fullscreen. We don't want
this--fullscreen surfaces should always be aligned to the screen--so add
the same check that seatop_default already does when entering this mode.
Tested with Weston's weston-fullscreen demo, which sends a move request
if you click anywhere on its surface.
When REAPER submenu is closed `XCB_CLIENT_MESSAGE` with type
`NET_ACTIVE_WINDOW` is sent to set focus to parent menu.
Closes: https://github.com/swaywm/sway/issues/6324
If the destroyed xwayland view is in transaction, it won't
be destroyed immediately. wlr_xwayland_surface then becomes
dangling pointer.
Closes#6605Closes#5884
On server request, we need to send configure events to inform the client
of the new intended size. If the client changes size itself, sending a
configure event will only cause problems.
Use transaction_commit_dirty_client to distinguish between the two
transaction causes.
Pending state is currently inlined directly in the container struct,
while the current state is in a state struct. A side-effect of this is
that it is not immediately obvious that pending double-buffered state is
accessed, nor is it obvious what state is double-buffered.
Instead, use the state struct for both current and pending.
xdg_shell and xwayland handled geometry changes differently despite
needing mostly identical behavior. The xwayland implementation has been
changed to match that of xdg_shell.
The size of a tiled container cannot change in response to new buffer
sizes, so there is no need to commit a new transaction. Instead, simply
recenter the view with the new geometry, leaving the full transaction
flow for floating containers.
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.
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
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.
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
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.
In case xcb-iccm is not installed on the system, size_hints will be
null. Handle this as if the get_constraints functions was not
implemented and return the defaults.
Fixes#4870
Previously, Xwayland windows did not have size_constraints implemented,
resulting in the window being resizable. This implements the constraints
through the X11 size hints supplied by the window itself.
When changing a surface from managed to unmanaged in handle_map(), the
call to handle_destroy(.., view) causes the sway_xwayland_view pointed
to by the untyped wlr_xwayland_surface.data field to become invalid
garbage, yet the untyped wlr_xwayland_surface.data continues to point
at it. In particular: view_get_*(view_from_wlr_surface(..)), even
with appropriate NULL checking, will crash sway when this codepath is
exercised (reliable test case: drop-down menus in Google Earth).
The documentation for wayland-server.h says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
Replacing wayland-server.h with wayland-server-core.h allows us to drop the
WL_HIDE_DEPRECATED declaration.
This commit si similar to wlroots' ca45f4490ccc ("Remove all wayland-server.h
includes").
This honors the fullscreen output request for
`xdg_toplevel_set_fullscreen` and `zxdg_toplevel_v6_set_fullscreen`.
If the request was sent before mapping, the fullscreen output request
will be retrieved from the client_pending state for the toplevel. The
output will be passed to `view_map` and if there is a workspace on the
output, the view will be placed on that workspace.
If the request comes in after being mapped, the view will be moved to
the workspace on the output (if there is one) before becoming
fullscreen.
This fixes a crash in `container_init_floating` when a xwayland view
sends a configure request while in the scratchpad.
`container_init_floating` gets called so the configured minimum and
maximum sizes gets respected when resizing to the requested size. Since
the workspace was NULL, it would SIGSEGV when attempting to get the
workspace's output for the output box retrieval.
This extracts the resizing portion of `container_init_floating` into a
separate function. If the container is in the scratchpad, it will just
be resized and skip the centering.
Additionally, `container_init_floating` has been renamed to
`container_floating_resize_and_center` to more accurately describe what
it does.
This introduces a `default` seat operation which is used when no mouse
buttons are being held. This means there is now always a seat operation
in progress. It allows us to separate `default` code from the standard
cursor management code.
The sway_seatop_impl struct has gained callbacks `axis`, `rebase` and
`end`, and lost callbacks `finish` and `abort`. `axis` and `rebase` are
only used by the default seatop. `end` is called when a seatop is being
replaced by another one and allows the seatop to free any resources,
though no seatop currently needs to do this. `finish` is no longer
required, as each seatop can gracefully finish in their `button`
callback. And `abort` is not needed, as calling `end` would achieve the
same thing. The struct has also gained a bool named allow_set_cursor
which allows the client to set a new cursor during `default` and `down`
seatops.
Seatops would previously store which button they were started with and
stop when that button was released. This behaviour is changed so that it
only ends once all buttons are released. So you can start a drag with
$mod+left, then click and hold right, release left and it'll continue
dragging while the right button is held.
The motion callback now accepts dx and dy. Most seatops don't use this
as they store the cursor position when the seatop is started and compare
it with the current cursor position. This approach doesn't make sense
for the default seatop though, hence why dx and dy are needed.
The pressed_buttons array has been moved from the sway_cursor struct to
the default seatop's data. This is only used for the default seatop to
check bindings. The total pressed button count remains in the
sway_cursor struct though, because all the other seatops check it to
know if they should end.
The `down` seatop no longer has a `moved` property. This was used to
track if the cursor moved and to recheck focus_follows_mouse, but seems
to work without it.
The logic for focus_follows_mouse has been refactored. As part of this
I've removed the call to wlr_seat_keyboard_has_grab as we don't appear
to use keyboard grabs.
The functions for handling relative motion, absolute motion and tool
axis have been changed. Previously the handler functions were
handle_cursor_motion, handle_cursor_motion_absolute and
handle_tool_axis. The latter two both called cursor_motion_absolute.
Both handle_cursor_motion and cursor_motion_absolute did very similar
things. These are now simplified into three handlers and a single common
function called cursor_motion. All three handlers call cursor_motion. As
cursor_motion works with relative distances, the absolute and tool axis
handlers convert them to relative first.
This makes it so the container gets resized by a configure request for
xwayland floating views. The minimum and maximum sizes are also
respected. Previously, the configure request was resizing the surface
to the size requested, but never changing the container size. This
caused the surface to be rendered outside of the container or to be
smaller than the container. The former is never ideal and the latter
makes no sense for floating views since the container itself can just
be shrunk.
The goal here is to center fullscreen views when they are both too small
for the output and refuse to resize to the output's dimensions. It has
the side effect of also centering the view when it's too small for its
container.
Example clients that have this behaviour are emersion's hello-wayland
and weston.
It works by introducing surface_{x,y,width,height} properties to the
container struct. The x and y represent layout-local coordinates where
the surface will be rendered. The width and height are only used to
track the surface's previous dimensions so we can detect when the client
has resized it and recenter and apply damage accordingly.
The new surface properties are calculated when a transaction is applied,
as well as when a view resizes itself unexpectedly. The latter is done
in view_update_size. This function was previously restricted to views
which are floating, but can now be called for any views.
For views which refuse to resize *smaller* than a particular size, such
as gnome-calculator, the surface is still anchored to the top left as
per the current behaviour.
