This makes the code a bit more readable IMHO (and forces us to be
consistent with event handler function names).
Adjust scripts/checkpatch.pl to not complain.
xsurface->data is presumed to be a (struct view *) if set, so it must be
left NULL for an unmanaged surface. Otherwise view_from_wlr_surface()
may return a (struct xwayland_unmanaged *) where a (struct view *) was
expected, leading to a crash.
valgrind backtrace:
Invalid read of size 1
at 0x48F8FFC: wlr_scene_node_set_enabled (wlr_scene.c:903)
by 0x124C9F: ssd_set_active (ssd.c:323)
by 0x124C9F: ssd_set_active (ssd.c:318)
by 0x124C9F: view_set_activated (view.c:215)
by 0x118851: focus_change_notify (seat.c:353)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x48FC8F2: wlr_seat_keyboard_enter (wlr_seat_keyboard.c:298)
by 0x119E60: seat_focus.lto_priv.0 (seat.c:473)
by 0x1248FD: seat_focus_surface (seat.c:491)
by 0x1248FD: unmanaged_handle_map (xwayland-unmanaged.c:51)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x490FC91: surface_commit_state (wlr_compositor.c:499)
by 0x56A24F5: ffi_call_unix64 (unix64.S:104)
by 0x569EF5D: ffi_call_int.lto_priv.0 (ffi64.c:673)
Address 0xa0e15ff30788b68 is not stack'd, malloc'd or (recently) free'd
Fixes: 4028a9482f
("seat: use focus_change event to update focused/active view")
XWayland views can self-declare that they don't want keyboard focus via
the ICCCM WM_HINTS property. Most of the logic is already in place to
avoid giving focus to such views (e.g. taskbars).
Add a couple of missing pieces to make this work:
- Hook up view_isfocusable() to look at WM_HINTS for XWayland views
- Adjust desktop_focus_topmost_mapped_view() to skip unfocusable views
Follow-up from b816c16701
Chase wlroots: Stop using wlr_xwayland_surface event data
Chases: 27edd024f83892f4af9c5084d47b73f26966aaf1
xwayland: pass NULL as event data
This is a trivial cleanup to make xwayland_view_create() symmetrical with
xwayland_unmanaged_create(), and avoid the need to access view->impl from
xwayland-unmanaged.c.
The return value of xwayland_view_create() is no longer user, so return void.
No functional change.
- Move xwayland-specific struct definitions to new xwayland.h header
- Move xwayland_move_sub_views_to_front() from desktop.c to xwayland.c
- Split out xwayland_server_init/finish() from server_init/finish()
- Rename new_xwayland_surface -> xwayland_new_surface and
xwayland_surface_new() -> handle_new_surface() for consistency
- Add "mapped" argument to xwayland_unmanaged_create() so that we can
make unmanaged_handle_map() private to xwayland-unmanaged.c
Since xwayland commit 9e4b7948df5a9a67632bb606150ec171b5519672
there is a one-second delay between XWayland surfaces being
unmapped and destroyed. This revealed that we were not actually
handling the unmap() signal correctly for unmanaged surfaces.
Fix a couple of glitches seen when exiting interactive move/resize:
- Cursor briefly set to left_ptr rather than the correct cursor image
- Cursor not updated if the view being moved/resized is destroyed
Also make sure to exit interactive mode if the view is going fullscreen
(labwc gets very confused otherwise).
Code changes in detail:
- Factor out set_server_cursor() which will set the correct cursor
image for non-client areas (either XCURSOR_DEFAULT or one of the
resize cursors).
- Unify the logic from cursor_rebase() and process_cursor_motion by
factoring out cursor_update_common(). This corrects some logic
discrepancies between the two, which should be a good thing(TM).
- Remove the extra cursor_set(XCURSOR_DEFAULT) from interactive_end()
and instead rely on cursor_update_focus() to do the right thing.
- Simplify cursor_button() by just calling interactive_end() when we
want to exit interactive mode.
- Call cursor_update_focus() from view_destroy() if the view had mouse
focus or was being interactively moved/resized.
v2: Eliminate force_reenter parameters and figure out automatically
when we need to re-enter the surface.
v3: Rename wlseat -> wlr_seat.
v4: Simplify client/server cursor logic.
- When XDG and XWayland views are positioned (view_moved()).
- When unmanaged XWayland surfaces are mapped, unmapped, or moved.
Do not update cursor focus during an out-of-surface drag.
Along with the existing call in desktop_move_to_front(), this
should hopefully cover the majority of cases where the cursor focus
could get out-of-date, with the possible exception of layer-shell
surfaces.
- Eliminate multiple "return" paths in unmanaged_handle_unmap(), which
were a bug waiting to happen.
- Use wl_list_for_each_reverse() rather than wl_list_for_each() to find
the topmost (most-recently-created) unmanaged surface.
- Only call desktop_focus_topmost_mapped_view() if the unmapped surface
was actually focused.
Previously, when unmapping and not finding another unmanaged surface
to give keyboard focus to we were not doing anything. With this patch
we will give focus to the topmost mapped view which is the same
behavior that also happens when an usual X11 surface unmaps.
This fixes dmenu when being exited with ESC.
Reported-by: @Flrian
This is a similar fix to 065c37d3f5 but for unmanaged windows. The issue
could be seen for example when moving the undocked Search Tool window in
Audacious. For unmanaged windows, we don't track any pending move/resizes,
so just process all client configure requests immediately.
Set node position in the configure/set_geometry handlers when moving a
window in response to a client request.
Steps to reproduce weird positioning fixed by this patch:
1. Start leafpad
2. Open Help->About
3. Move the dialog
4. Close the dialog
5. Open it again
6. Drag it and observe a jump in position
There is also an xwayland PyQt5 script in PR #428 which demonstrates
jumpy position.
- Add missing call to wlr_scene_node_set_position() in
unmanaged_handle_commit() -- this fixes moving unmanaged XWayland
windows.
- Update view->pending_move_resize when we receive a configure request
for a managed XWayland surface -- this fixes moving managed but
undecorated XWayland windows.
- Also update view->pending_move_resize when we move a surface while a
configure request is already pending -- this fixes a discrepancy
between displayed and actual position for XWayland windows that try to
set their own initial position, but then get overridden by labwc's
positioning.
Moving undecorated XWayland windows is still really glitchy -- it appears
that an XWayland window gets sent incorrect mouse motion coordinates when
there is a pending configure request moving the window itself.
Sway handles some xwayland events that labwc still does not. This commit
just starts to rig up some handlers for these with log messages if they
are caught.
- set_geometry: try to handle, but cannot find an application that uses
it, so is untested.
- request_activate - just log caught event
- override_redirect - just log caught event
This is needed to allow X11 applications to create surfaces as
non-override_redirect and then change them to override_redirect later
Without this gitk-menus and rofi are treated as xwayland-views with
associated server-side-decoration and forced positioning.
