There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
By default, gitlab skips checking out of submodules. So far this
didn't matter to us, as meson will initialize submodules as part
of setup.
It no longer does for the dist command however, and as we run it
from a separate job where the submodule checkout isn't preserved,
the job breaks with recent meson versions.
Fix this by instructing gitlab to checkout the submodule for all
jobs that need it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2371>
Don't try to initialize and then enable an extension if it is not supported
in the current mode. Otherwise the extension will not be initialized, and the
initial ERROR state is not cleared. Once it is in ERROR state we can't enable
it anymore when we switch mode. Instead, leave the extension in INITIALIZED
state, so that it will be initialized when appropriate. This happens for
extensions that support the unlock-dialog mode but not the user mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2378>
Screenshots use `%Y-%m-%d %H-%M-%S` for the timestamp, which has the
advantage of allowing proper lexicographical sorting.
The screencast file name pattern, on the other hand, uses
locale-dependent expansions, which break sorting based on file name, and
introduces the chance of potentially invalid characters on different
file systems.
Fixes: #5115
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2300>
`ShouldShowAirplaneMode` only considers whether airplane mode
should be shown for the form factor, not whether there are
any actual kill switches available.
That's tracked in a separate property, `HasAirplaneMode`.
Take that into account for our `:show-airplane-mode` property,
so that it reflects when airplane mode should and *can* be shown.
Right now we only show airplane mode when it is enabled (and
therefore available), but this will change in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that by constructing the proxy manually, and then
initialize it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
In case where there are multiple in- or output devices, pulseaudio
or pipewire can pick the "wrong" one by default.
Allow users to change devices without opening sound settings by
adding a submenu to the sliders when there is more than one device.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2380>
Since IBus does not provide this information right away, we
so far cannot do much about providing a truthful anchor position
for the preedit text. But with the Mutter API in place it will
be up to this object to do so in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2384>
When gjs overhauled its coding style, it opted for disallowing
spaces around braces in object literals: `{foo: 42}`.
We opted out of that particular rule in commit 09b8e8f, primarily
because it would have been a very intrusive change with the old
style of object literals:
```js
let oldStyle = { foo: 42,
bar: 23 };
```
Alas, all multi-line object literals have been transitioned to
the new style where braces go on separate lines, so they are no
longer subject to the rule one way or the other.
Nowadays the rule mostly affects destructuring, and there it
is a bit odd to apply different spacing rules to arrays and
objects:
```js
const [foo, bar] = someArray;
const { baz, quz } = someObject;
```
This is now the main divergence from the canonical gnome style,
and the only one where we directly contradict it.
It would be good to transition away from that, and as the rule
now only affect destructuring and single-line object literals,
we can do that on a case-by-case bases by moving the override
to the legacy configuration.
As desctructuring imports makes up a fair share of the affected
code, and those will change when moving to ES6 modules, this
seems like a good moment to start that transition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2375>
This behavior dates back all the way to the original gnome-shell
release, and it did make sense at the time:
- we were first to make notifications persistent instead of
closing them after a timeout; apps were therefore used to
treat notifications as fire-and-forget instead of closing
them when no longer relevant
- neither web notifications not portals did exist yet, so the
D-Bus API was only used directly, instead of as a backend
for other APIs; as a result, focusing the app was more likely
than not to put the source of the event that the user was
notified about into view
Nowadays both persistent notifications and web notifications
are wide-spread, so the original reasons no longer apply.
This change helps web notifications in particular, as it reduces
the differences between XDG and portal-based implementations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2332>
libadwaita has a new About window, and GNOME apps are expected
to use it going forward instead of GtkAboutDialog.
Comments are meant to be detailed, and are no longer shown in the
main view. So we remove the old comments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2373>
GNOME Shell will only update extensions if the org.gnome.Extensions
app is present. This commit adds alternative support for
com.mattjakeman.ExtensionManager to the extension updating mechanism.
It enables updates to occur when extension-manager is the sole installed
tool on the system. When both applications are installed,
org.gnome.Extensions is preferred at all times.
Fixes#5564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2358>
