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>
libadwaita has a new About window, and GNOME apps are expected
to use it going forward instead of GtkAboutDialog.
Comments are meant to be detailed, and are no longer shown in the
main view. So we remove the old comments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2373>
If one of these libraries breaks its GIR API in future, then upgrading
packages unrelated to gnome-shell might pull in the newer version,
causing gnome-shell to crash when it gets a newer GIR API that is
incompatible with its expectations. For example, this seems to be
happening in Debian testing at the moment, when GNOME Shell 41.4
imports GWeather and can get version 4.0 instead of the version 3.0 that
it expected.
Adding explicit API versions at the time the newer version is released
is too late, because that will still let the newer version of the GIR API
break pre-existing GNOME Shell packages. Prevent similar crashes in
future by making the desired versions explicit.
This is done for all third-party libraries except GLib, similar to the
common practice in Python code; if GLib breaks API, then that will be
a disruptive change to the whole GLib/GObject ecosystem, regardless.
Gvc, Meta, Shell, Shew, St are not included because they're private
(only exist in a non-default search path entry).
Clutter and Cogl *are* included, because we need to import the fork of
them that comes with Meta, as opposed to their deprecated standalone
versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1008926
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2261>
