Currently there is no indication that an extension had an error except
for the sensitivity of the switch (which may have a different cause).
This is useful information to users, so add a small error indicator
alongside the updates icon and show the actual error in the details.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2337
Currently the switches handle position reflects the requested
extension state (as in: the user (de)activated the switch),
while the actual extension state is reflected by the underlying
state.
That doesn't work well when the switch is insensitive though (for
example on error), because the desaturation neuters the color
that reflects the state.
Address this by resetting the switch handle to the state when
making it insensitive.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1263
We kept the old binary name when overhauling the tool for the Extensions
app to avoid unnecessary churn for packagers/distributors.
However we now have a reason to "free" the old name, so rename the binary
to match the (sub)project name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
As of mozjs68 (gjs-1.64) `globalThis` is recommended over `window` and
it makes more sense in this context anyways. Migrate the few instances
of `window` we use and adjust the eslint configuration.
`window` will continue to resolve to `globalThis`, so this won't affect
extensions or other downstream users.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2322closes#2322
When creating an extension interactively, we currently always use
the default template unless the --template option is used.
Instead, display the list of available templates to the user and
prompt them to pick one if it wasn't specified.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
When we allow users to choose between different templates, we should
provide some context for each template to facilitate that choice.
Add that metadata in the form of a .desktop file, which allows us to
specify name and description, and is well supported by our translation
infrastructure.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
The template used when creating a new extension is intentionally
minimal, as the sample code in the old extensions-tool proved to
be annoying more often than not.
However as we support per-command options, we don't have to limit
ourselves to a single template, and can offer alternatives for
common use cases.
To prepare for that, namespace the existing template by moving it
into a subfolder.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
When using the create command's --interactive option, we prompt for
any metadata that wasn't passed on the command line. As every prompt
is preceded by a short multi-line description, it is hard to follow
when everything is lumped together.
Improve legibility by separating all prompts by newlines.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
Commit 4589da957 added D-Bus API for enabling/disabling extensions,
use that if possible to provide better feedback and not clutter the
settings with non-existent UUIDs.
The old code path is preserved as fallback to keep the commands
working from outside a running shell session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
UninstallExtensions() only returns whether the operation was successful,
not why it failed. However we know that only user extensions can be
uninstalled, so check that first to provide a more meaningful error.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
For the prefs command, we first fetch the extension info to check
whether the extension exists and actually has preferences. This
pattern can be useful for other commands and properties, so split
out a generic helper function.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
Error reporting is useful when used interactively, but often undesirable
when used in scripts. Account for that with a common --quiet option,
which is more convenient than redirection stderr to /dev/null.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
Predefined categories aren't a great way for organizing installed
applications, but they have their use in "stores" like Software
or flathub.
Not listing any category means we fall through the cracks, so
pick the (hopefully) least inappropriate one ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1160
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
We finally have everything in place for distributing the Extensions app
as flatpak without jumping through too many hoops. Add a manifest that
can produce a nightly build like other GNOME modules, and can serve as
a template for a stable manifest on flathub.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
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
In order to support OpenExtensionPrefs()'s parentWindow parameter,
we will need the ability to make a window transient to an external
window identified by a string handle.
This takes the corresponding code from xdg-desktop-portal-gtk and
brings it into an introspectable form, likewise the counterpart in
libportal to export a string handle for a GtkWindow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1087
While sandboxing isn't a concern for the gnome-extensions command line
tool, using the Extensions proxy directly means that D-Bus methods are
called from the tool rather than gnome-shell, which allows the proxy
to auto-shutdown when done.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
Whether we install bash-completion support currently depends on whether
the corresponding pkg-config dependency is found.
Turning this into a feature option keeps that behavior by default, but
also allows to explicitly enable or disable the support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1072
I always forget to keep the extension-tool version number in sync when
doing a new release. Given that it's unlikely that I'll do much better
in the future by myself, make distcheck fail when the versions don't
match.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1076
Some (newer?) GCC versions complain when a g_auto variable isn't
initialized when declared, even when the initialization is guaranteed
to happen before the variable is used or goes out of scope.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2298
Now that we support extension updates, it may be useful to list
pending updates from the command line. It's easy enough to support,
so add a corresponding option to the list command.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/988
After creating a new extension, we try to open the main source
file with the default handler, which fails when there is none.
But given that the extension was created successfully, don't treat
a missing handler as failure, and print the path to the new extension
instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/905
While we can now build gnome-extensions-tool as stand-alone project,
we are currently missing any translations, as those are part of
gnome-shell.
The easiest option for addressing this would be to symlink the toplevel
po directory into the subproject, however that would mean duplicating
the entire gnome-shell message catalogs.
So instead, set up a bare po directory and provide a script to populate
it from the translations in the toplevel po directory.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
The gnome-extensions tool code is really independent from the rest of the
code base, and could be used either as part of the gnome-shell build or as
stand-alone project (for example for the extension-ci docker image).
We can actually support both cases by moving the code to a subproject.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
gvc has made some recent changes that rename its user options
following meson guidelines for GNOME packages[0].
The options used in gvc as a subproject have been renamed
accordingly.
[0] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
When using the meson build system, gvc will be built as a subproject.
As meson restricts submodules to a subprojects/ directory in the
source tree root, move the submodule there.
https://bugzilla.gnome.org/show_bug.cgi?id=783229
