Now that we no longer provide a portal implementation ourselves,
the only expected callers are the GNOME portal implementation
and (since recently) the remote desktop daemon.
Make that explicit and restrict callers to these senders, like
we do for other D-Bus APIs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3411>
Try h264 on intel and AMD hardware using VA-API, using vapostproc
to do the color conversion using specialized hardware. We're not adding
a vaapi pipeline using the color conversion GL shader here, as vapostproc
color conversion should be better suited for anything needed by vaapi
based encoders/decoders.
A capsfilter is used to enforce the use of DMAbuf (memory:DMABuf) with
the new explicit modifier API (format=DMA_DRM).
Also, we're using the new va* gst elements instead of the vaapi* ones
here, as the vaapi* elements are deprecated, while the va* elements are
actively maintained.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080>
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>
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>
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>
