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>
We set the expand-fraction property of the workspace thumbnails on changes
to their should-show property. The should-show property defaults to true, and
the expand-fraction property defaults to 1. The should-show property gets
updated in the constructor of the ThumbnailsBox though, and it might become
false (that is the case when starting up the shell) during construction.
In this case we're not yet listening to "notify::should-show" in the
ControlsManager, and therefore forget to update the expand-fraction
accordingly. Fix that and ensure the expandFraction is always set to the value
we expect after hiding or showing the thumbnails (we call _updateThumbnailsBox()
from _update(), which we call in the constructor).
This should be the proper fix for the problem that 9bf550da8 (which caused
the workspace thumbnails to never show) originally tried to fix.
Fixes: 9bf550da88 ("overviewControls: Set expandFraction for ws thumbnails to 0 when hidden")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7668
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3323>
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>
There are cases where it makes sense to have fillPreferencesWindow be
async, so await it. One such case is when using .ui files from resources
with (GTK) templates. When extension developers load the resource in
`fillPreferencesWindow` and then import the js file that registers the
classes, there will be an error at the moment that there is no UI
provided. Similarly, make getPreferencesWidget async optionally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3348>
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>
