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>
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>
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>
A feature that works for server side decorated windows only that
only adds slightly more convenience over the regular "move" action that
is still there.
Keeping it around would complicate some cleanups in upstream Mutter
so just drop it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3332>
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>
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>
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>
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>
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>
We no longer provide a portal implementation, so there's no need
for owning the name. Right now only the gnome portal consumes
the API, and that accesses it under "org.gnome.Shell".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3326>
We use the pagePadding to adjust for the large indicators that we add on the
left and right of the appGrid.
While the original padding needs to be applied to the padding for the
indicators (as it was in super.vfunc_style_changed already), there's no
reason to add an extra row and column spacing to the pagePadding on all
sides, so remove that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
We multiply the spacing around the workspace thumbnails with the
expandFraction so that it grows with the animation to show/hide them. We
shouldn't factor in the extra spacing to accomodate for the thumbnails in
case they're hidden though, so make sure expandFraction is set to 0 after
the thumbnails got hidden.
This fixes the spacing when a user never uses workspaces (and the workspace
thumbnails are never shown), and also the first transition from
hidden->shown for the thumbnails, which currently starts at 100% scale (ie.
pops into existence).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
With a previous commit we've made the overall dynamic spacing dynamic, but
the spacing is now a bit much when it comes to the space between search and
workspaces minimap, just as workspaces minimap and large workspaces.
The minimap should somewhat "squeeze into the empty space" here, so
reduce the spacings above and below it a bit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
The naming of the appGridBox is quite confusing, as it actually
describes the box of the workspaces strip, but in the appGrid state of
the overview. Change that name and call it workspacesBox instead, which
seems to make more sense here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
After the recent notification changes, the title may still be null
when the source is originally added. Handle that case and make sure
we pick up later title changes by setting up a property binding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
Adding a notification clearly constitutes a count change, but
the notify call was accidentally dropped during the overhaul
of the notification API.
Fixes: 34f05b075b ("messageTray: Let the tray decide whether to show a
banner")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
The fallback path broke when we removed support for window icons.
Nowadays we track all windows, and as a result should always have an
associated app (although not necessarily backed by a .desktop file),
so this shouldn't make a difference in practice. Not to mention that
external docks (like cairo-dock) are extremely rare themselves now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3295>
Override redirect windows manage their own positioning and size alone
and are always sticky, so we're not covering them either with the
animation MonitorsGroup, and thus there's no need to clone them or we'd
end up having two windows painted.
This was causing the shell tray icon window actors (that have no opacity
by default but that are override redirect) to show up during the
animation as their clone animation is not 0.
The other option would be hide them during the animation phase, but
there's no need for this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3285>
'icon-missing' is not an actual icon name. It somewhat works
because an invalid icon name will fallback to the correct
'image-missing', however for apps the generic app icon is
a better fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3248>
Unfortunately it turned out that this change does increase frame skips
in the recorded files on several tested devices, greatly outweighing
any small visual benefit it might have.
This reverts commit 490ecc536ab6b2f9320592930be5aae473297934.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3268>
