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
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
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
There are a couple of D-Bus services that are currently provided by
gnome-shell for which it makes sense to move them fully or partially
into separate processes:
- screen recording (performance)
- FDO notifications (security)
- Extensions (portalization)
Add some base classes and build system glue to take care of the
common boilerplate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This is what most GNOME modules now use instead of a shell script,
which makes sense given that the build system itself is written
in python.
This particular copy comes from nautilus ...
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/920
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
Make gjs to compute the GType name for registered GObject-derived
classes using the file basename and the first directory name, so that we
can avoid name clashing, and ensure that no extension will break the
shell by registering a name that is already used (by the shell or by any
other extension).
This requires gjs commit 02568304 [1] that will be part of release 3.35.2,
so bump the required version as gjs does post-release version bumps.
[1] https://gitlab.gnome.org/GNOME/gjs/merge_requests/337https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/790
Extensions are uploaded to extensions.gnome.org as zip files that
not only contain the extension sources, but also compiled GSettings
schemas and message catalogues. To make this more convenient, add
a corresponding command for creating an archive suitable for up-
loading.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
While we don't actually require a more recent version at build time,
we do need the latest stable version at runtime. There's no strong
reason for making that differentiation, so bump the requirement.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1006
