Like the mutter 40.alpha.1.1 release, we missed adjusting to a
GSettings schema move from g-s-d to gsettings-desktop-schemas,
resulting in an abort on startup with the latest released
gnome-settings-daemon.
The man pages don't change very often, but draw in both docbook and
asciidoc. The latter is particularly problematic, as some distros
still ship only a python2 version of the tool.
Address this by generating the man pages at dist time, and including
the result in the tarball.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1553>
I messed up and released 40.alpha at the same time as 3.38.2, when it's
supposed to be in January. In order to re-align with the schedule, change
the upcoming version to 40.alpha2 so we don't have to skip a release and
will be back on track in time of 40.beta.
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
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
