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>
When the app is properly launched, D-Bus activation will be followed
by a call to org.freedesktop.Application.Activate() to open the window.
But it's also possible for D-Bus activation to happen in other
circumstances, for example during gdbus command line completion.
We don't want to pop up a window then, so pass the --gapplication-service
flag to properly separate D-Bus activation from activating the app.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2076>
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>
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.
With the previous preparations in place, it is time to take the plunge.
As both the app and the portal use the same small library for handling
external windows, port everything at once to avoid the hassle of building
and installing two versions of the library.
With the portal using GTK4 now, all extensions must port their preference
widgets as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
Unlike in previous GTK version (or Clutter), destroy() no longer
breaks reference cycles but just releases the reference held by
GTK itself.
So any reference we hold - either the explicit property or any signal
handlers that bind the window as `this` - prevents the window from
being disposed when closed, and the application won't quit.
Work around this by explicitly running dispose() on the window when
it is removed from the application.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
GTK4 will remove the GtkHeaderBar:title property, so stop using it
and set the window's title property instead, as that's what headbars
use in both GTK3 and GTK4 unless explicitly overridden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
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>
