(cherry picked from commit 4b3bc8f1)

Alessandro Bono authored Aug 19, 2024 and Marco Trevisan committed Sep 02, 2024

Move ShellUserVerifier creation to its own function so that
extensions can easily override it.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7828
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3446>

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>

See: https://gitlab.gnome.org/GNOME/Initiatives/-/issues/51

# Conflicts:
#	subprojects/extensions-app/data/metainfo/org.gnome.Extensions.metainfo.xml.in

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3374>

Code that uses async/await is often easier to follow than callbacks, in
particular as part of the code is already async.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3439>

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>

The underlying value only changes asynchronously, which makes a
setter a bit awkward, so replace it with a public async function.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3439>

Reword names, functions and refactor code to make code execution logic
simpler to understand.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3439>

We have recently bumped GNOME OS baseline to x86_64_v3 and
this caused issues with x86_64_v2 runners.

See https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1665

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3464>

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>

All timing parameters should take the `slow-down-factor` and
`enable-animations` settings into account, but the delay parameter
of property/adjustment animations was forgotten.

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>

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>

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>

When the accessibility option "Reduce Animation" is turned on, the
accessibility option "Locate Pointer" stops to work. This is because
the animation is not marked as required. Mark it as such.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7472
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>

We need the full link so let's warn contributors about this instead of
having reviewers pointing this out.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3465>

Gitlab also recognizes variants like "close #123" or "Closed #123".

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3465>

Our convention is to use "Fixes" lines for references commits
(like belated "fixups") and use "closes" for issues.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3465>

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 dd97a258

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3466>

Update NEWS.