With the new borderless style of libadwaita, the global switch in the headerbar
did not look good. Moving it to the main view is the opportunity to also move
the content of the information popover.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2114>
If the finish function isn't specified, promisify will now try
to use the async name without '_async'/'_begin' suffix (if any)
and '_finish' appended.
Everything except IBus uses a variation of that pattern, so there's
quite a bit of boilerplate we get to remove…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2174>
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>
