An action can be performed both on a signal emitted by a window or by
a well-known signal name, so that one can do:
[window-id]::signal => command
And so these would work:
w/1::position-changed => resize w/2 20 30
::monitors-changed => move w/1 30 40
We only support "monitors-changed" global signal name or connecting to
window signals for now, but this can be easily expanded adding support
for more global signal values or parsing other kinds of object instances
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
Allows to use:
set_strut 0 0 MONITOR_WIDTH*0.5 MONITOR_HEIGHT/4 top [default]
We use the currently focused window as the reference monitor if any or
the primary one if no monitor is explicitly provided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We may need to compare monitor size to fractions and while it can be
done using inverse divisions, they were not supported as we didn't parse
floating point values.
So, just add support for both multiplications and divisions, so that we
can easily do stuff like `MONITOR_HEIGHT*3/4`.
Additions would be easy to support too if we don't care about operator
priorities, but that's out of scope for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We just made an half assed attempt to wait, but e.g. when clients were
waiting for a frame event, the attempt was not enough, as the clients
would not ack any configure until the time they were scheduled to paint
again.
Fix this by actually tracking newly pending configurations, and waiting
for them to return.
On X11, still be lazy and hope for the best, as there is no similar
configuration tracking there.
Some tests were updated to use just 'wait' when there was no actual need
for any extra waiting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
When a client resizes on its own, make sure the new size is passed
through the window constraints machinery directly, to trigger any
potential window management rule that might apply.
Fix a couple of tests to make use of this behavior by introducing a new
'wait_size' command that waits until a window has been resized to a
expected size.
This replaces the fix introduced in 0e736af301 ("window: Ensure
constraints after a Wayland client resize").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3700>
Tests that
* the window under the cursor has focus
* focus_default_window won't move the focus away from a previously
focused window even if the cursor is somewhere else
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
New add_monitor command for adding secondary monitors. Support setting
the workspaces-only-on-primary preference.
The stacking test tests the focus and stacking for multiple monitors
with workspaces-only-on-primary=true. The default_focus changes
previously broke this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
The "later" API is used to queue actions in relation to compositing,
thus is owned by the MetaCompositor instance. Make users of this
functionality get MetaLaters instance from the compositor, and stop
using the global meta_later() API.
display: Use non-singleton MetaLater API
tests: Use non-singleton MetaLater API
meta/common: Make docs refer to context aware MetaLater API
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means we can eliminate the use of scattered singletons that isn't
added by the tests or the test framework itself.
tests: Don't get backend from old singleton getter
Either use the ownership chain, or the explicit test context instance
pointer.
tests/wayland: Pass context to test client constructor
So that we can get the Wayland compositor directly from the context.
tests: Don't get display from singleton
tests/client: Make test client carry a context pointer
tests/runner: Have test cases carry a context pointer
tests/wayland/test-driver: Get backend from context
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Instead of having users of the test client manually deal with alarm
filters, let the test client automatically add itself as filters. This
changes the MetaX11Display a bit, to handle an array of filters instead
of a single filter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
Gnome-shell uses meta_display_focus_default_window() when shell elements
loose focus which is the case with Alt+Tab window switching. Globally
active input clients don't immediately gain focus though so if
meta_display_focus_default_window focuses a wrong window stacking and
focus don't behave as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
New commands to set the number of workspaces, activate a workspace, with
and without focus, move windows to specific workspaces, and check the
stacking on a specific workspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This will allow tests to change monitor resolution. The first argument
is the monitor ID; there is always one monitor added by default, and it
has the id 0. It's currently not possible to add more monitors, so
passing '0' is the only valid way to resize monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This hasn't worked for a while, since the test always runs the nested
backend, meaning it's a Wayland compositor. To unblock testing window
management in combination to monitor changes, lets remove the
unreachable X11 WM paths, so that we can start using virtual monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The Xwayland server can go away at any time; when this happen we might
have a test client running, and for it to tear down more nicely, make
sure to avoid trying to clean up X11 resources on the old X11 display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The 'stop_after_next' will execeute one command, then not return to the main
loop until a 'continue' command is passed. Commands will still be
processed between 'stop_after_next' and 'continue'.
This is intended to be used to induce race conditions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
This will require some symbol exporting, but the benefit is that have
better control of what external test cases can do in terms of creating
more testing specific contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
