As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.
When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.
However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.
So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.
Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.
Added metatests verifying these situations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.
So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).
Added a stacking test to verify this.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When requesting to a take-focus window to acquire the input, the client may or
may not respond with a SetInputFocus (this doesn't happen for no-input gtk
windows in fact [to be fixed there too]), in such case we were unsetting the
focus while waiting the reply.
In case the client won't respond, we wait for a small delay (set to 250 ms) for
the take-focus window to grab the input focus before setting it to the default
window.
Added a test for this behavior and for the case in which a window takes the
focus meanwhile we're waiting to focus the default window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
Allow to set/unset WM_TAKE_FOCUS from client window.
This is added by default by gtk, but this might not happen in other toolkits,
so add an ability to (un)set this.
So fetch the protocols with XGetWMProtocols and unset the atom.
test-client now needs to depend on Xlib directly in meson build.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
Don't launch the stacking tests in one single shot, to allow better debugging
and being able to launch just one single test using meson test.
Those tests can now be all launched with:
meson test --suite stacking [single-test-name]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
This is the last remaining feature necessary to achieve
parity with the Autotools build.
A few changes were made to the install locations of the
tests, in order to better acomodate them in Meson:
* Tests are now installed under a versioned folder (e.g.
/usr/share/installed-tests/mutter-4)
* The mutter-cogl.test file is now generated from an .in
file, instead of a series of $(echo)s from within Makefile.
Notice that those tests need very controlled environments
to run correctly. Mutter installed tests, for example, will
failed when running under a regular session due to D-Bus
failing to acquire the ScreenCast and/or RemoteScreen names.
Meson uses the 'dependencies' field to determine and
parallelize build steps, but that isn't entirely true
with 'link_with'; this might cause a race condition
when generating header files while trying to build
them.
Fix that by only using 'dependencies' instead of 'link_with'.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
