The portal login window uses WebKit, which is a security-sensitive
component that not all vendors want to support.
Support that case with a build option, and update the captive
portal handler to use the user's default browser if the portal-helper
is disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
When NetworkManager detects limited connectivity, we currently
pop up the portal helper window immediately. This can both be
disruptive when it happens unexpectedly, and unnoticeable
when it happens during screen lock.
In any case, it seems better to not pop up a window without
explicit user action, so instead show a notification that
launches the portal window when activated.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7688
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
VA-API low-power encoder profiles (such as vah264lpenc) reduce power consumption by relying entirely on fixed-function hardware blocks.
Use vah264lpenc over vah264enc by default, in order to save on energy and 3D engine capacity.
Signed-off-by: José Relvas <josemonsantorelvas@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3416>
Mutter has a new tool for interacting with mutter with features we don't
expose to users yet. It can be exported as a dbus service but it is not
done so by default. This adds an easy way to do so without having to
remember some JS snippet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3425>
When an app folder is opened it would do so without grabbing the
keyboard focus, so one could not navigate with the arrow keys without
pressing Tab. This adds the focus parameter to popup()'s grab, which
sets the key focus to the elements of the folder when it is opened.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3338>
The AppFolderDialog would lose keyboard focus after editing the title
(likely due to the folder entry grabbing key focus). This commit adds
navigate_focus() to _showFolderLabel() to send key focus back to the
dialog's elements after editing the title.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3338>
In commit e69da36095d5093c1c7bec7a9c96c079c0b837f9, Florian Müllner
wrote:
> We currently complete the animation using an onComplete handler,
> which only runs if the corresponding transition was stopped when
> finished.
>
> While it is unexpected that the transition is interrupted, it can
> apparently happen under some circumstances (like VMs with qlx).
> The consequences of that are pretty bad, mainly due to the cover
> pane that prevents input during the animation not getting removed.
>
> Address this by always completing the animation when the transition
> is stopped, regardless of whether it completed or not.
There are effectively four branches of the startup animation:
1. if Meta.is_restart() is true, no animation is run on startup; I
believe this is the X11-only case of restarting the shell
mid-session.
2. if Main.sessionMode.isGreeter is true, just the panel is eased onto
the screen; this is the GDM case.
3. if Main.sessionMode.hasOverview is true, then a whole sequence of
animations are run; this is the normal session case.
4. otherwise, the whole UI zooms in to full size, and from full
transparency to full opacity; this is the Initial Setup case.
The fix above handles cases 2 and 4, but not 3. This patch applies the
same fix to case 3, so that the callback is always called on session
startup even if the transition is interrupted.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3422>
All styling currently happens on the ScrollView child, which
means that instead of a scrollbar inside the dialog to move
the content, we have a scrollbar next to the dialog that moves
the dialog as a whole.
Fix this by simply moving the style classes to the up-most parent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3414>
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>
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>
If `params` is floating when provided by the caller, and if one of the
early return paths is taken from this function, the call into GIO never
sinks and takes ownership of the `GVariant`, and hence it’s leaked.
Always explicitly sink the input variant as soon as the function is
called, then it can’t be leaked.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3396>
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>
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>
