| Age | Commit message (Collapse) | Author |
|---|
|
Fixes: https://github.com/swaywm/wlroots/issues/1469
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Since xwm only manipulates the stack when focusing a window, newly
mapped windows should be stacked below the focused window. This prevents
the newly mapped window from stealing focus due to being on the top of
the stack.
|
|
This prevents some annoying issues when e.g. not including wlr/config.h or
making a typo in the guard name.
|
|
We spent literally hours trying to debug this. Turns out it's a typo.
Kill me.
|
|
|
|
|
|
|
|
An X11 client can leave the hints->input WM hint unspecified,
by not setting the XCB_ICCCM_WM_HINT_INPUT flag in hints->flags.
In that case, we should assume a sane default.
Make the hint default to true, so that clients which do not specify
the hint, like mupdf, still get keyboard focus.
This should fix swaywm/sway#2231
|
|
It's not used (XCB_IMAGE_FORMAT_Z_PIXMAP comes from xproto.h) and we
don't even have a pkg-config dependency on xcb-image, making the build
to fail on that inclusion on systems without the package.
|
|
|
|
|
|
|
|
Adds a modal property to indicate whether the surface wants to be a
modal.
|
|
153f37bdf57c61e7fb09162a6791afe8b9b4d0ef (#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.
This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.
The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.
A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is https://github.com/swaywm/sway/issues/2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
|
|
surface: add wlr_surface_role.precommit
|
|
This reverts commit ef0a6ea4d2934ec014d791150c42348061ec4f7f, reversing
changes made to 8d03bc9178d8544cbcd24293ece6ac9f1698e602.
|
|
|
|
|
|
|
|
The override_redirect flag can change on configure notify and
on map notify. This adds an event to know when it changes.
This removes wlr_xwayland_surface_is_unmanaged which was wrongly
using the window type to decide whether the view should be
unmanaged.
A similar patch was proposed to Weston, but has never been
merged upstream [1].
[1]: https://patchwork.freedesktop.org/patch/211161/
|
|
This allows to emit the unmap event before the surface becomes
actually unmapped for most shells.
|
|
|
|
surface: replace wlr_surface_set_role_committed with wlr_surface_role
|
|
|
|
|
|
|
|
Enable the stack update again for focus changes on non-focusable views.
|
|
|
|
|
|
Happens when e.g. closing gimp.
==24039==ERROR: AddressSanitizer: heap-use-after-free on address 0x6150001a7a78 at pc 0x7f09b09f1bb2 bp 0x7ffcf0237bf0 sp 0x7ffcf0237be0
WRITE of size 8 at 0x6150001a7a78 thread T0
#0 0x7f09b09f1bb1 in wl_list_remove ../util/signal.c:55
#1 0x7f09b094cf03 in xwayland_surface_destroy ../xwayland/xwm.c:295
#2 0x7f09b0950245 in xwm_handle_destroy_notify ../xwayland/xwm.c:717
#3 0x7f09b095304a in x11_event_handler ../xwayland/xwm.c:1149
#4 0x7f09b0c68f01 in wl_event_loop_dispatch src/event-loop.c:641
#5 0x7f09b0c67601 in wl_display_run src/wayland-server.c:1260
#6 0x40a2f4 in main ../sway/main.c:433
#7 0x7f09b011018a in __libc_start_main (/lib64/libc.so.6+0x2318a)
#8 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
0x6150001a7a78 is located 120 bytes inside of 496-byte region [0x6150001a7a00,0x6150001a7bf0)
freed by thread T0 here:
#0 0x7f09b2b58880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
#1 0x7f09b094d1a1 in xwayland_surface_destroy ../xwayland/xwm.c:315
#2 0x7f09b0950245 in xwm_handle_destroy_notify ../xwayland/xwm.c:717
#3 0x7f09b095304a in x11_event_handler ../xwayland/xwm.c:1149
#4 0x7f09b0c68f01 in wl_event_loop_dispatch src/event-loop.c:641
#5 0x7f09b0c67601 in wl_display_run src/wayland-server.c:1260
#6 0x40a2f4 in main ../sway/main.c:433
#7 0x7f09b011018a in __libc_start_main (/lib64/libc.so.6+0x2318a)
#8 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
previously allocated by thread T0 here:
#0 0x7f09b2b58e50 in calloc (/lib64/libasan.so.5+0xeee50)
#1 0x7f09b094b585 in xwayland_surface_create ../xwayland/xwm.c:119
#2 0x7f09b0950151 in xwm_handle_create_notify ../xwayland/xwm.c:706
#3 0x7f09b0953032 in x11_event_handler ../xwayland/xwm.c:1146
#4 0x7f09b0c68f01 in wl_event_loop_dispatch src/event-loop.c:641
#5 0x7f09b0c67601 in wl_display_run src/wayland-server.c:1260
#6 0x40a2f4 in main ../sway/main.c:433
#7 0x7f09b011018a in __libc_start_main (/lib64/libc.so.6+0x2318a)
#8 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
|
|
Fixes #927
|
|
|
|
7f70d244a9802207c258bd5da6d4ada5eb15484a made utility windows
managed, because it made sense according to the spec. Turns out
Firefox uses them for popups.
|
|
xwayland: forward configure events to compositor when unmapped
|
|
Some comboboxes (e.g. in chrome://flags) are advertized as…
Notifications of course! Yeah, notifications, the thing that
tells you you have mail, your battery is low, or the dog has
eaten your carpet. This isn't the first time we notice Chromium's
X11 backend is pretty shit.
Anyway, added notifications and splash screens to the list of
unmanaged windows. Also removed utility windows because those
should be managed, but maybe I'm wrong and I'll revert this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows compositors to access the surface being unmapped. This
is also more consistent with the destroy signal.
|
|
|
|
|
|
|
|
|
|
This fixes drag'n'drop support for Chromium.
|
|
|
|
|
