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>
Replace deprecated functions with their direct replacements:
- dep.get_pkgconfig_variable() → dep.get_variable()
- prg.path() → prg.full_path()
- source/build_root() → project_source/build_root()
In one case we need meson.global_source_root() that was only
added in meson 0.58, so bump the requirement to that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2077>
We currently ignore any error that may occur when calling the
OpenExtensionPrefs D-Bus method. Right now such an error is highly
unlikely, given that we already checked that we are running under
gnome-shell and the extension in question exists and has prefs.
We'll soon make sure that only one dialog is shown at any time,
which is an error that we can realistically expect, so handle that
properly.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
We have initTranslations() for binding an extension's
gettext domain, but nothing to help with using gettext
from an extension.
Such help would be useful though, as an extension that
calls textdomain() like a normal application would
inadvertently changes the default domain for the whole
gnome-shell process.
Instead, extensions have to use domain-specific versions
of the gettext functions:
```js
const Gettext = imports.gettext.domain('my-extension');
const _ = Gettext.gettext;
```
Make this a bit easier by adding those functions directly
to the extensions object when initTranslations() is called,
then expose helper functions for calling them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2594
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
