Graphene uses C99 and includes stdbool.h, which adds a
new 'bool' type. Clutter has an a11y test that names a
variable as 'bool' too, and they do not play well together.
Rename this variable to boolean.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
This is a deprecated property that is not used anywhere
in the codebase. Not by GNOME Shell. Because it uses the
deprecated ClutterGeometry type, it's a good target for
cleaning up, given that ClutterGeometry will be dropped
later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
If an intersection is empty, the (x, y) coordinates are undefined, so
just use the work area and in-progress constrained window rect when
sliding according to the SLIDE_X or SLIDE_Y custom placement rule.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
When check_only is TRUE, the constraint should not be applied, just
checked. We failed to comply here when a placed transient window was
to be moved together with its parent, updating the window position
directly even if check_only was TRUE.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
If a client maps a persistent popup with a placement rule, then resizes
the parent window so that the popup ends up outside of the parent,
unmanage the popup and log a warning about the client being buggy.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
When a parent window is moved, attached windows (attached modal dialogs
or popups) is moved with it. This is problematic when such a window
hasn't been shown yet (e.g. a popup that has been configured but not
shown), as it'll mean we try to constrain an empty window. Avoid this
issue by not trying to auto-move empty windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
Currently, it is assumed that if querying the EGL_TEXTURE_FORMAT of a
Wayland buffer succeeds it is an EGLImage. However, this assumption will no
longer hold on upcoming versions of the NVIDIA EGL Wayland driver which
will include support for querying this attribute for EGLStream buffers as
well. Hence, we need to check if buffers are EGLStreams first.
Fixes#488https://gitlab.gnome.org/GNOME/mutter/merge_requests/477
Fixes condition duplicated:
/* If a contains b, just remove b */
if (meta_rectangle_contains_rect (a, b))
{
delete_me = other;
}
/* If b contains a, just remove a */
else if (meta_rectangle_contains_rect (a, b))
{
delete_me = compare;
}
Closes https://gitlab.gnome.org/GNOME/mutter/issues/480
Traditionally visual alerts were implemented by flashing the focus
window's frame. As that only works for windows that we decorate,
flashing the whole window was added as a fallback for client-decorated
windows.
However that introduces some confusing inconsistency, better to just
always flash the entire window.
https://gitlab.gnome.org/GNOME/mutter/issues/491
When commit 91c6a144da synced shadows with Adwaita, it removed the
shadow completely from attached modal dialogs. However Adwaita uses
the same shadow for all dialogs (modal or not), so do the same here.
https://gitlab.gnome.org/GNOME/mutter/issues/490
The app menu always was a GNOME-only thing, so after it was removed this
cycle, assuming that it is not displayed by the environment is a better
default.
https://gitlab.gnome.org/GNOME/mutter/issues/493
As it was originally reported on
https://bugzilla.gnome.org/show_bug.cgi?id=779234#c0, the hottest path was
convert_ubyte() in mesa. Reverting this shows no trace of those hot paths,
nor any higher than usual CPU activity.
As the improvements at the time were real, I can only conclude that pixel
conversion was happening somewhere further the pipeline, and swizzling just
helped indirectly. That got eventually fixed, so swizzling just stayed to
cause grief. And lots it caused.
Time to bin this, it seems.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/486
The function finish_cb can be called as a result of a call to ca_context_cancel
in cancelled_cb. This will result in a deadlock because, as per documentation,
g_cancellable_disconnect cannot be called inside the cancellable handler.
It is possible to detect if the call to finish_cb is caused by ca_context_cancel
checking if error_code == CA_ERROR_CANCELED. To avoid the deadlock we should
call g_signal_handler_disconnect instead g_cancellable_disconnect if this is the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/474
Splitting out the X11 display initialization from display_open() broke
restoring the previously active workspace in two ways:
- when dynamic workspaces are used, the old workspaces haven't
been restored yet, so we stay on the first workspace
- when static workspaces are used, the code tries to access
the compositor that hasn't been initialized yet, resulting
in a segfault
Fix both those issues by splitting out restoring of the active workspace.
https://gitlab.gnome.org/GNOME/mutter/issues/479
We use the input_method on both branches, but only check for its existence
when enabling the text_input. The case of focusing out shouldn't happen in
practice as we couldn't have focused in ever before, but still make the
check one level above so it's clearer that the text_input's IM focus cannot
be enabled without an IM implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/432
Enable the OSK if receiving .enable consecutively (i.e. the
ClutterInputFocus was already focused). We specifically want to avoid
enabling the panel just because of focus changes within a surface (where
the .disable request across focus change would previously unfocus the
ClutterInputFocus). Prior state should be preserved if possible in that
situation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/432
The ClutterVirtualInputDevice API was fixed to use Clutter button
internal codes, whereas the mousekeys still uses evdev codes.
Change the mousekeys implementation to use the Clutter button code
instead to remain compatible with the ClutterVirtualInputDevice API.
Fixes: 24aef44b (Translate from button internal codes to evdev)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/473
Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to
some limitations in XTestFakeKeyEvent, the remapping has to be done in the first
xkb group/layout. In case there are two or more keyboard layouts enabled and the
selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval
will fail to retrieve the correct keycode for a remapped keyval. Let's use the
reserved_keycodes map in order to retrieve the correct keycode if needed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/443
