When a window is in the background and should not have the cursor on top
of it, its _cursor will be null. By getting the texture through it, we
add this extra check, which was missing before, leading to a cursor
drawn at 0, 0 on windows where it should not have been drawn.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2702>
909616b208 seems to have wrapped window actors in a container, so the actor.has_pointer check started failing. Instead, switch to meta_window_has_pointer () which doesn't rely on window actor implementation details.
We check for existence of has_pointer first just in case someone attempts to run gnome-shell 44.1 with mutter 44.0 which does not have the function exported publicly yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2710>
Add common test environment variables to a default test setup so that they
don't need to be repeated everywhere.
Also ensures that we're always using the gsettings memory backend to never
interfere with local environment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2661>
GSettings schemas are now compiled at install time, so it is no
longer necessary to include the compiled schema in the archive.
However the `gnome-extensions pack` command hasn't been adjusted,
so that it can still be used to produce valid archives for all
supported versions.
To not let that code linger forever, error out when building
a version where GNOME 44 is the oldest supported release.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2639>
Whether or not animations should be enabled depends on various
factors, some of which may change at runtime. We therefore
track changes, and sync the setting by calling inhibit/uninhibit
as necessary.
Except that we never actually record the new state, so when animations
are disabled, we end up inhibiting them every time
the setting is synced, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2698>
Even though commit b89d90eb8 talked about the GLib.BookmarkFile
type, this didn't stop the code from sneaking a silly typo and
refer to this GLib.BookmarksFile (i.e. extra 's').
Fix the code to refer to the right type name and constructor.
Fixes: b89d90eb8 ("screenshot: Use GLib.BookmarkFile to save recent screenshots")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2692>
In GNOME OS, due to a misconfiguration, geoclue was configured without
systemd support. In that configuration, geoclue does not install its
systemd .service file (geoclue.service) but it (incorrectly) includes
the following line in its D-Bus service file:
SystemdService=geoclue.service
As a result, when dbus-daemon tried to activate it at gnome-shell's
request, it would fail with:
Unit geoclue.service not found
Then, GeoclueAgent._onGeoclueVanished() would be called, as the
name_vanished_handler passed to Gio.bus_watch_name(). This is consistent
with Gio.bus_watch_name()'s documentation:
> You are guaranteed that one of the handlers will be invoked after
> calling this function.
But that function assumed that this._managerProxy is defined, leading
to:
JS ERROR: TypeError: this._managerProxy is undefined
_onGeoclueVanished@resource:///org/gnome/shell/ui/status/location.js:163:9
Fix this by checking for nullishness of this._managerProxy. (Strictly
speaking, it's undefined rather than being null, but other code in this
file already uses the vaguer '!= null' test, which considers undefined
to be null.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689>
We created the socket window using the same coordinates that mutter uses
for its own off-screen windows created via
meta_x11_display_create_offscreen_window() and that are filtered out in
MetaWindowX11's is_our_xwindow().
This caused these windows to be never tracked by mutter and then we
never received a "::window-created" signal that should lead a ShellTrayIcon
to associate itself as the clone of the created MetaWindow.
So, still keep it offscreen, but at different location.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2684>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2681>
There is only a very limited subset of GTK that is usable from
within the compositor, and by now we should have replacements
for all of them in place.
On the other hands there is plenty that can go catastrophically
wrong in the rest. In particular on wayland, GTK must never open
a wayland display connection.
Make sure that extensions don't do anything silly, by disallowing
all GDK backends.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2680>
