Instead of having the name of the directory be X-GNOME-Utilities. This
also allows translating the name to the user's language. The name is
chose to be different to X-GNOME-Utilities from GNOME Menus.
In the process, also remove the categories. The menu definition from
gnome-menus is not used, and it's not a category that apps list
themselves, so it's completely unused anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3526>
- remove unnecessary dialog type-specific padding, spacing and margin definitions that led to layout to problems
- bump the size of user avatar in authentication dialog
- nest css classes in the sass to better reflect the structure of dialog elements
- sync style of audio device selector with switcher-popup style
- sync text and padding styles with other elements
- fix incorrect button order in audio selection dialog
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7876
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3473>
The Meta keybinding API now exposes the Clutter event to GJS, which was
previously hidden due to it being a gpointer. Since this moves the
binding argument one argument to the right on the GJS side, any code
that was using the binding argument needs to be updated.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3502>
As the keyboard is released asynchronously after setting the ibus
engine, there's a possibility that the `this._reloading` property
changed in the meantime.
To ensure that `holdKeyboard()` and `releaseKeyboard()` are correctly
paired, record the condition in a local variable so that it maintains
its value in the callback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>
When commit ce89b15bb123d made the code async, it did not only
delay releasing the keyboard until after the engine has been
updated, but also the following code that updates the current
input source.
One result is that the current source is now initialized later,
which breaks any code that relies on the source being set.
This affects the login screen in particular (which uses different
`InputSourceSettings` than the regular session): It fails to come
up entirely if the OSK is enabled.
To fix the issue, use a .then() callback to release the keyboard,
instead of blocking all following code with await.
Fixes: ce89b15bb1 ("ibusManager: Use async await instead of callbacks")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7912
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>
We had code to ensure that all the queued messages sent by a PAM module
were shown by waiting some time to give the user time to read them, but
due to a typo this code never executed.
Fixes commit dd97a2589b8b686f273550f3e9e6ce370b25c10d
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3466>
The ripples are used both for the "Hot Corner" animation and for the
"Locate Pointer" animation. The latter one is an accessibility feature
and should always work, even when animations are disabled. Take this
into account.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
There are cases when we want to mark an animation as required. For
example, we want the "Locate Pointer" animation to work even when
the animation as marked as disabled. Take this into account when
easing an actor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
There are cases when we want to mark an animation as required. For
example, we want the "Locate Pointer" animation to work even when
the animation is marked as disabled. Take this into account when
adjusting the animation time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
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>
