It's more common to use the dedicated .rst suffix for reStructuredText
files, so now that the files were ported,
use that.
(Renaming the files separately from changing it is less likely
to confuse git, thus the separate commit)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3454>
It's as human-readable as asciidoc and produces the same results,
but the tooling is more widely supported. Also both GLib and GTK
switched to it for their man pages, so rst2man is already a
dependency of the platform.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3454>
The original asciidoc project is still stuck on python2, so on
distros that didn't switch to a fork (like Fedora), it pulls
in over 100M of legacy dependencies.
However we are about to move our man pages to reStructuredText
which doesn't have that issue, and which is already used for
GLib's and GTK's man pages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3454>
Since GNOME 44, extension schemas are compiled at install time.
At the time GNOME 46 is released, this will be all supported versions,
so start relying on it and drop the old compatibility
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3042>
Now that both the website and the Extension app support the custom
"version-name" field, we should expose it in the CLI tool as well.
As a more developer-oriented tool, keep showing the automatic
version along-side the new field when both are set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3034>
We currently only create boilerplate code for the actual
extension. Now that libadwaita has largely standardized
preference UIs, it makes sense to allow creating the
prefs.js boilerplate as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2889>
The Extension/Preferences classes are where we will focus for
future extension convenience API, so developers should be
encouraged to use them as entry points.
Adjust the existing templates to do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
GSettings schemas are now compiled at install time, so it is no
longer necessary to include the compiled schema in the archive.
However the `gnome-extensions pack` command hasn't been adjusted,
so that it can still be used to produce valid archives for all
supported versions.
To not let that code linger forever, error out when building
a version where GNOME 44 is the oldest supported release.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2639>
Extensions can export asynchronous enable() and disable()
functions. To guard against re-entrancy when enabling or
disabling an extension, this commit adds two new states:
ENABLING and DISABLING which are set immediately prior
to calling enable() and disable() respectively.
This commit updates the extensions CLI and Extensions app
with new strings for these states.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2364>
