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>
The extensions site recently added support for a custom
"version-name" string in metadata:
gitlab.gnome.org/Infrastructure/extensions-web/-/merge_requests/154
This allows developers to control the version that is exposed to
users. As the version according to the developer is almost always
more relevant than the automatic version assigned by the website,
use it instead of the "version" field if set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2995>
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>
We currently include a fake config.js file to satisfy the indirect
import from ExtensionUtils. However we're about to need to pass
build-time information into the program ourselves, so generate
a proper file.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2841>
GTK 4.12 deprecates gdk_wayland_toplevel_unexport_handle() in favor
of the new gdk_wayland_toplevel_drop_exported_handle(). We are not
bound by API stability, so we can just expose the additional argument
that the replacement requires instead of tracking the handle
internally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2778>
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>
After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
