During session startup, we have the following chain:
LayoutManager._prepareStartupAnimation()
`- LayoutManager._startupAnimation()
`- LayoutManager._startupAnimationComplete() (a)
| or
`- LayoutManager._startupAnimationGreeter() (b)
| or
`- LayoutManager._startupAnimationSession() (c)
`- Overview.runStartupAnimation() (d)
`- OverviewActor.runStartupAnimation() (e)
`- ControlsManager.runStartupAnimation() (f)
Branch (b) calls LayoutManager._startupAnimationComplete() once the
animation is complete. Branch (c) does the same, except that
ControlsManager.runStartupAnimation() is an async function that awaits
LayoutManager.ensureAllocation().
LayoutManager._prepareStartupAnimation() is an `async` function, and its
caller catches & logs any error it raises.
Previously, ControlsManager.runStartupAnimation() – (f) in the above
diagram – was declared `async`, because it uses `await` internally, but
also accepted a callback, which was called on successful completion of
the function and the animation it triggers.
If an exception is raised during execution of the function, its callback
would never be called, and because the promise it implicitly returns is
discarded, the exception would never be logged either. And, stepping a
few levels up the call stack, the callback that
LayoutManager._startupAnimationSession() (c) provided would never be
called, and so LayoutManager._startupAnimationComplete() would never be
called, meaning the cover pane that prevents input would never be
removed and the session would be unusable.
Remove the callback parameter from ControlsManager.runStartupAnimation()
(f), and instead make it resolve in the case where the callback would
previously have been called.
Remove the callback parameter from OverviewActor.runStartupAnimation()
(e) – it is just a wrapper around ControlsManager.runStartupAnimation().
Adjust Overview.runStartupAnimation() (d) accordingly: rather than
passing a callback to OverviewActor.runStartupAnimation(), await its
return and then proceed. There is a slight behaviour change here:
previously, in the branch where this._syncGrab() is false, the callback
would be called before calling this.hide(), whereas now this.hide() is
called before the async function returns.
Adjust LayoutManager._startupAnimationSession() and its siblings to be
async, rather than each calling _startupAnimationComplete() directly.
Finally, in _prepareStartupAnimation() await _startupAnimation() either
succeeding or failing, and in either case call
_startupAnimationComplete(), removing the cover pane that prevents all
input.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3428>
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>
