The return value currently indicates whether the request was
successful, namely `setCompletionEnabled(false)` will return
`true` if completions were successfully disabled.
However the only caller that uses the value uses it to indicate
whether completions were enabled.
Given that nothing else uses the value, change the meaning to
match the caller, and indicate whether completions are enabled
after the call returns.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3439>
When creating a new NM connection they are by default system connections. A
user cannot create them if they don't have the correct polkit permissions
(org.freedesktop.NetworkManager.settings.modify.system).
If a user tried to add a new connection in the drop down menu, then they got
no password prompt and NM logged the following:
[...] audit: op="connection-add-activate" pid=1872 uid=1000 result="fail" \
reason="Insufficient privileges"
This change adds the current user to the user permissions for the new
connection, if the user has no permissions to modify the system connections,
which copies the behavior of GNOME Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3462>
The coordinates are effectively in the windowing system coordinate
space, which when scaling Xwayland, we need to scale these. Do this with
the Meta.Window.protocol_to_stage() function on the focused window,
which handles it correctly for the corresponding windowing system and
configuration.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3458>
There are cases where this._user might be null when a session
is opened. This is because the user is not selected via GDM but
it is set through PAM. This happens when logging with smart card
or with credential managers, for example.
Given the session-id of the opened session, look for the owner.
This fixes the following error:
```
gnome-shell[153293]: TypeError: this._user is null
Stack trace:
_findConflictingSession@resource:///org/gnome/shell/gdm/loginDialog.js:1219:26
_onSessionOpened@resource:///org/gnome/shell/gdm/loginDialog.js:1254:51
@resource:///org/gnome/shell/ui/init.js:21:20
```
Fixes: df84854d9 ("loginDialog: On login, allow logout a conflicting session")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7526
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
The conflicting session is owned by the same user per definition.
Use the Name property of the conflicting session to get the
username instead of assuming that `this._user` is defined and
passing the username around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
Since commit df84854d9073c457d79d7c2e6a5750428c52ff01 the function
_onSessionOpened() is now async. This means that if an error occurs
we get the following warning:
```
gnome-shell[1014]: Unhandled promise rejection. To suppress this
warning, add an error handler to your promise chain with .catch()
or a try-catch block around your await expression. Stack trace of
the failed promise:
_onSessionOpened@resource:///org/gnome/shell/gdm/loginDialog.js:1166:27 @resource:///org/gnome/shell/ui/init.js:21:20
```
Follow the suggestion and add a try-catch block in order to reveal
what the error is. In the catch phase, reset the faded AuthPrompt
otherwise we can't retry with another user.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
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>
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>
