When the inner radius of the top left corner is 0, the corresponding arc
does not get drawn, resulting in a path going from the bottom left
corner to the top right corner when the path is closed.

Fix this by always including a line_to from the bottom left to the top
left corner.

Fixes: dde13b30 ("st/theme-node-drawing: Trace the correct path for inset box shadows")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7996

appstream-util is deprecated in favor of appstreamcli. The new tool
does not have a `validate-version` command, so implement the check
in directly in the check-version.py script.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3520>
(cherry picked from commit 7405f7c3)

Everything, including flathub[0], should be using appstreamcli
now, so stop supporting the old tool as well.

[0] https://docs.flathub.org/blog/improved-build-validation

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3520>
(cherry picked from commit a79d517c)

So they properly show up in the docs.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3518>
(cherry picked from commit 38cca627)

SPDX has become the established standard for expressing FLOSS
licenses, and is what meson itself strongly recommends for the
license field.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3521>
(cherry picked from commit 86be4e31)

This improves the recognizability of these buttons.

Also, remove the button a11y labels, as Orca
tooltips are also read by Orca.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3529>
(cherry picked from commit 8a80dbec)

As we have removed is_client_decorated from Mutter in the last release.
Instead of re-adding it and re-exposing SSD/CSD differences and making
gnome-shell deal with that, we created a new API that does exactly what
is_client_decorated was used for, so switch to using that.

Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7984

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3522>
(cherry picked from commit d92f8daf)

Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:

    Whenever you’re describing a function that takes a callback, you
    should always annotate the callback argument with the argument that
    contains the user data using the (closure argument) annotation

    You should not annotate the data argument with a unary (closure).

    The unary (closure) is meant to be used when annotating the callback
    type

Recently gobject-introspection became a bit more strict with this and
that generated some warnings:

    Warning: St: invalid "closure" annotation: only valid on callback
    parameters

This commit fix all the closure annotations.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3535>
(cherry picked from commit 411fe9c4)

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3532>
(cherry picked from commit b3c16a48)

Dialogs should not use titles that are too long to fit, but if
they do, wrapping is more appropriate than ellipsizing.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3540>
(cherry picked from commit fbaead35)

Also, hide its menu item from the a11y tree, similarly to the volume and
other sliders.

Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6894

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3538>
(cherry picked from commit 685a7948)

When representing the keyboard backlight levels as discrete items,
it is currently not possible to keynav past the first button.

Fix this by bypassing the usual event bubbling and passing key press
events directly to the focus manager, similar to what we do for
popup menu items.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3545>
(cherry picked from commit 64c9baf4)

Point the discrete level buttons to the corresponding labels,
so that they don't appear as plain "button" in screen readers.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3545>
(cherry picked from commit 83a88100)

The extended-us layout is currently using actions/keyvals inconsistently for
its backspace keys, use the "delete" action consistently, just like we do in
all other OSK layouts (including the newly added za-extended layout).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3549>
(cherry picked from commit 7a4c9718)

The parameter used to be optional until commit d54219c0, but
after GObjectifaction `undefined` is no longer interchangeable
with `null` here.

Restore the old behavior, as it's used by extensions (including
one of our own templates).

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8068
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3548>
(cherry picked from commit 4ebc7113)

A lot of keys have no action set. In that case key.action is `undefined`,
but the strict equality check of `action !== null` here will return true and
we'll enter the if-case anyway.

That's quite confusing and was not intended like that, so change the
comparison to a less-strict operator.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
(cherry picked from commit 91ffc4c0)

Looks like we currently do the press-and-release dance for keys that specify
both a keyval and the "modifier" action. So when pressing CTRL in the
extended OSK, not only is the CTRL modifier set together with the next key
pressed, but the actual CTRL keyval quickly gets pressed and released,
similar to how we'd do it for the TAB key.

This seems unintentional, as the press-and-release behavior should probably
be specific to keys like TAB, and not apply to modifier keys, so limit that
behavior to only keys without an action specified.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
(cherry picked from commit cae8b745)

If the shift key was pressed, we should switch back to the default level
after the next commit. It seems that this only worked due to a superfluous
signal emission so far (see https://gitlab.gnome.org/GNOME/mutter/-/issues/3448).

When the keyboard is in this "shift" level (note: only "shift", not
"opt+shift" level) without being latched, there are certain events that
should put it back into the default level:

- A normal character key on the OSK being pressed
- A keyval on the extended OSK (eg. TAB key or an arrow key) being pressed
- The backspace key being pressed
- The OSK being hidden
- The user moving focus in the entry

The `_updateLevelFromHints()` function already takes care of updating the
active level after certain kinds of events, we can achieve the desired
behavior by adding a fallback case to that function where it moves the level
back from "shift" to "default".

Since we only want this switch back to the "default" layer as a response to
actual user input, add a `userInputHappened` boolean to
`_updateLevelFromHints()` and don't set that when the application simply
changes its content hints.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
(cherry picked from commit 12d25321)

gnome-system-log, vinagre and gnome-dictionary were deprecated a long time ago

The gnome-abrt desktop file name was also changed a long time ago to a rDNS one

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3539>
(cherry picked from commit de4f1c3f)

Update NEWS.