ExtensionUtils was originally used for shared functions between
the extension system and the (old) prefs-tool, but then gained
useful API meant for extensions themselves.
It's a bit weird to mix the two, so split out the extension convenience
API into a separate module.
We will soon split up the module further, and add specific "flavors"
for extensions and preferences, with the current code providing a
shared base for both.
That should explain both the new location and the odd module name. :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
When gjs overhauled its coding style, it opted for disallowing
spaces around braces in object literals: `{foo: 42}`.
We opted out of that particular rule in commit 09b8e8f, primarily
because it would have been a very intrusive change with the old
style of object literals:
```js
let oldStyle = { foo: 42,
bar: 23 };
```
Alas, all multi-line object literals have been transitioned to
the new style where braces go on separate lines, so they are no
longer subject to the rule one way or the other.
Nowadays the rule mostly affects destructuring, and there it
is a bit odd to apply different spacing rules to arrays and
objects:
```js
const [foo, bar] = someArray;
const { baz, quz } = someObject;
```
This is now the main divergence from the canonical gnome style,
and the only one where we directly contradict it.
It would be good to transition away from that, and as the rule
now only affect destructuring and single-line object literals,
we can do that on a case-by-case bases by moving the override
to the legacy configuration.
As desctructuring imports makes up a fair share of the affected
code, and those will change when moving to ES6 modules, this
seems like a good moment to start that transition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2375>
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>
The Extensions app code is now independent enough from the rest of the code
base to move it to its own subprojects, like we did for the extensions-tool.
This allows for stand-alone builds of the app, which we are about to use
for distributing it as flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
I misremembered that imports.package.start() would set up the correct
gettext domain, but the module only provides a convenience method
for doing that.
Use it to bring back translations in the Extensions app, whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1108
