Unlike any other methods in the Extensions API, LaunchExtensionPrefs()
opens what appears to be an application dialog, except that it is
really a separate application that the caller has no control over.
In order to address that, add a new OpenExtensionPrefs() method that
takes additional parameters (modelled after the desktop portal APIs)
that will make it possible to improve the behavior in the future.
The new parameters are ignored for now, but pushing the API out now
will allow us to fill in the functionality post the .0 release.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The existing 'ExtensionStatusChanged' signal has a fixed set of parameters,
which means we cannot add additional state without an API break. Deprecate
it in favor of a new 'ExtensionStateChanged' signal which addresses this
issue by taking the full serialized extension as parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are currently enabled or disabled by directly changing the
list in the 'enabled-extensions' GSettings key. As we will soon add
an overriding 'disabled-extensions' key as well, it makes sense to
offer explicit API for enabling/disabling to avoid duplicating the
logic.
For the corresponding D-Bus API, the methods were even mentioned in
the GSettings schema, albeit unimplemented until now.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
