jasmine-gjs isn't widely available in distributions, so instead
of adding an obscure build dependency, include the subproject
in the tarball.
The --include-subprojects flag only applies to subprojects that
are used in the build, so we do not bundle gi-docgen that is
provided in the mutter image.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
Not until we've waited for leisure can we make precise assumptions about
otherwise animated actors sizes and positions, so do that before
checking fittsiness.
This should fix the flakyness of the fittsy test case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3398>
Currently overview windows added in workspace constructor lack monitoring
the skip-taskbar property. All other windows added after this have
this monitoring.
This uses existing code to correctly add the signal and removes all redundant
code.
It also insures all transients are handled correctly on initialization using
the existing code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3386>
(cherry picked from commit 8af8a27d91)
If there's a window flowing over the left edge in a workspace, the
animation of showing or hiding overview in the left adjacent workspace
would glitch, as the window would appear or disappear suddenly.
This commits tries to fix it by making sure the active workspace are
above other workspaces when updating workspaces or active workspace
changed in workspacesView.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7364
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3378>
(cherry picked from commit ab87629241)
The reduced border radius from st_theme_node_reduce_border_radius() depends
on the allocation size, and when it changes, has_large_corners can change.
has_large_corners is used to determine whether to pre-render using cairo,
so that means a change to the allocation size can influence whether the
pre-render using cairo should happen or not.
On changes to the allocation size we don't want to call render_resources()
though, but just update_resources() instead. And since we know now that
changes to the allocation size might cause pre-rendering to get enabled
or disabled, we need to do the "should pre-render" checks in
update_resources(), too.
So factor out those "should pre-render" checks into a new function
st_theme_node_maybe_prerender_background(), and then call that function from
both render_resources() and update_resources().
This fixes rendering artifacts with borders or rounded corners after changes
to the actor size.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6567
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3354>
(cherry picked from commit e1868cab1a)
When not logged in, the New Issue URL only redirects to an unhelpful
login page while the Issues page allows you to search for existing
issues and still offers a "New Issue" button.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3377>
(cherry picked from commit 5a99ba1a06)
CredentialManagers emit a user-authenticated signal with a token
upon a successful authentication. This marks the service as preempting
and will be used for the next login/unlock request. However, the
preempting service is not cleaned after a successful verification.
As a consequence, it will be picked on a second unlock request.
This doesn't happen after a succesful login request because there
is a transition from the gnome-shell process owened by GDM to the
one owned by the user.
Clean the preempting service on a successful verification, like we
do when the PAM conversation stops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3291>
(cherry picked from commit 258ad57b87)
`g_desktop_app_info_launch_uris_as_manager_with_fds()` was added
in GIO 2.57.2. We now depend on at least 2.79.2, so we no longer
need a fallback path for the case the function isn't available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3361>
(cherry picked from commit 55027bb084)
After the subproject moved to a meson wrap, its checkout is no
longer managed by gitlab.
While meson will take care of checking out required submodules
during setup, this will not happen for `test` or `dist`, so store
the checked out code in artifacts.
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3370>
(cherry picked from commit f0c14bdef3)
GtkWidget.set_size_request() enforces a minimum size, while
GtkWidget.set_default_size() simply sets the default size.
The docs of set_size_request() say "In most cases,
gtk_window_set_default_size() is a better choice for toplevel windows", and
in our case it doesn't seem necessary to prohibit the window from having a
smaller size, so switch to using the default_width and default_height
properties.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3307>
(cherry picked from commit 5aa89fa9e6)
If the idle callback is not explicitly removed when the notification is
destroyed, it may be invoked after destruction, and try to modify the
notification after it’s been freed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3352>
(cherry picked from commit 8176d6b51c)
Changing type when casting a double pointer is not strictly allowed in
C. In order to fix compilation with `-fstrict-aliasing`, don’t use
`g_clear_pointer()` for clearing this pointer where the type expected by
the destroy notify function does not match the type stored in the
`ShellCameraMonitor` struct.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3351>
(cherry picked from commit 37e49e8a22)
This was the type the function expected, but we were actually passing
the global context to it.
This didn't crash for some reason, but indeed it was wrong and we didn't
catch it because mutter side had not type-checks either
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3355>
(cherry picked from commit 9abad7f25f)
If no child setup is provided then all the shell extensions that use
GLib.spawn_async should actually use the shell spawning utils since we
are supposed to always restore the default nofile rlimit on launched
children.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit 64edd7940d)
Using child setup functions is unsafe in gjs code so let's warn if this
happens so that extensions using a similar codepath are warned.
This could be also part of gjs, but we provide a shell override since we
have alternatives to log about.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit 494be30764)
In the shell code we often use GLib.spawn_async to launch processes
with a GSpawnChildSetupFunc implementation in JavaScript to reset the
mutter nofile rlimit in the new child process.
However, this is highly unsafe to do because this implies that the child
setup function code is executed in gjs where a lot of allocations are
done and even more not-async-signal-safe code is executed, in fact
leading to dead-locks as reported in the past.
To prevent this, declare a new functions that do the same of the GLib
counterpart but without providing a GSpawnChildSetupFunc that is instead
implemented in the C-side doing the cleanup that mutter requires without
allocations or async-signal-unsafe code.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit 781010be66)
The child context setup function used as launch GSpawnChildSetupFunc
uses g_object_get that internally potentially allocates memory, making
it not async-signal-safe and so not something that is safe to use in
between fork and exec, so just use the simpler getter here.
Note that the current implementation of app_child_setup() is safe
already as sd_journal_stream_fd, dup2 and close are so.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit dcb5956dea)
In the future, the module will automate uploading the release
tarball. We already use the CI pipeline to generate the tarball,
so it's easy to hook up the module and provide some testing
before the module goes into production.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3340>
(cherry picked from commit 1fbfb93cbd)
We currently assume that the `CI_COMMIT_TAG` variable matches the
version component of the generated dist tarball.
That is usually correct, but sometimes errors happen and a wrong
tag is pushed, and the real release uses something like "46.0-real".
Account for that by building the artifact path from `meson introspect`
and exporting it as environment variable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3340>
(cherry picked from commit 27445a1c98)
The offset in high contrast mode was moving the dot too close to the
text making the spacing between the text, dot and hover highlight appear
visually unbalanced. Also it was making it more likely to overlap
descenders in the text.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
(cherry picked from commit 559d38c259)
With the dot now being placed correctly at the bottom of the hover
highlight it is now also overlapping the 1px inset shadow used as
outline in high contrast mode. To avoid this, shift the dot up
accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
(cherry picked from commit e2adc5a445)
The offset was given as a hardcoded (physical) pixel value and did not
take scaling into account. This lead to it being shifted closer towards
the icon as the scale increased.
This now replaces the hardcoded value with a CSS property which
automatically includes the scale factor.
Further this allows simplifying some calculations that previously were
trying to counteract the hardcoded offset using margins by using the
intended offset directly.
With this the dot in the dash is also now placed at exactly the bottom
of the hover highlight, while previously there was an unintentional 1px
space.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7488
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
(cherry picked from commit 31997fa2f9)
We currently compute the target scale from the allocated height,
which means that it only becomes available after thumbnails have
been allocated at least once at their expanded height.
As the minimap is initially hidden, this only happens after it is
expanded for the first time, which means the corresponding transition
is not animated.
In order to allow for a fix, compute the target height ourselves
to allow the scale computation to work independently from the
expand factor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3331>
(cherry picked from commit 2694a64ebb)
The auth prompt currently propagates all key presses, even the
Escape press that is used to cancel it.
On the lock screen that means that the same event that cancels
the prompt (and switches back to the clock) is *also* propagated
to the handler that activates the prompt on key press.
That handler doesn't do anything when the prompt is already visible,
which is the case when the transition to the clock is animated.
However when animations are disabled, canceling the prompt will
result in a new prompt getting created immediately, and the login
screen is stuck on the prompt.
Fix this by not propagating key events that are used to cancel
the prompt.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3317>
(cherry picked from commit e7dc0de75e)
The prompt itself may get destroyed when canceled, in which
case it is no longer possible to chain up in the vfunc.
This is usually not an issue as the prompt is only destroyed
at the end of a transition, but it results in a warning if
animations are disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3317>
(cherry picked from commit dac4f2cb86)
gsettings overrides can be in affect when XDG_CURRENT_DESKTOP is set. We
need predictable default values for predictable tests in mutter and thus
mutter will start asserting that GSETTINGS_BACKEND='memory' and
XDG_CURRENT_DESKTOP=''.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3329>
(cherry picked from commit beb3f120dd)
The fingerprint device fetching code has a generic error handler,
that assumes the passed in error is GError. If it's not a
GError it will fail trying to use GError specific methods.
This commit adds some validation checking.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3319>
(cherry picked from commit d8ab090d47)
