`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>
The iterator was pointing to NULL when going out of scope, leading to
autofree not clearing the list.
==300183== 32 bytes in 2 blocks are definitely lost in loss record 14,798 of 38,939
==300183== at 0x484586F: malloc (vg_replace_malloc.c:381)
==300183== by 0x4D7D980: g_malloc (gmem.c:127)
==300183== by 0x4D95AB3: g_slice_alloc (gslice.c:1074)
==300183== by 0x4D96D96: g_slist_prepend (gslist.c:282)
==300183== by 0x487854F: shell_app_get_windows (shell-app.c:794)
==300183== by 0x48791A1: shell_app_get_pids (shell-app.c:1201)
==300183== by 0x488B293: shell_window_tracker_get_app_from_pid (shell-window-tracker.c:702)
==300183== by 0x488B632: get_app_from_window_pid (shell-window-tracker.c:370)
==300183== by 0x488B632: get_app_for_window (shell-window-tracker.c:436)
==300183== by 0x488B632: track_window (shell-window-tracker.c:549)
==300183== by 0x4CDBB75: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==300183== by 0x4CD8BE9: _g_closure_invoke_va (gclosure.c:893)
==300183== by 0x4CF2A28: g_signal_emit_valist (gsignal.c:3406)
==300183== by 0x4CF2C2C: g_signal_emit (gsignal.c:3553)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2367>
The logging function cannot be asynchronous, so move the override
into main.js where ExtensionUtils can be imported at the top level.
Importing ExtensionUtils in environment.js at the top level is not
possible because it would import Main prematurely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
ES modules do not allow exports to be overriden, in anticipation
of the ESM port add a `setCurrentExtension` utility which will
throw if used in the shell. This is tested using a conditional
import of Main.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
Even though GNOME Shell is not explicitly using structured logging via
G_LOG_USE_STRUCTURED, GLib uses it as default since 2016 [1], and so
we're de facto using it.
As per this, if backtrace on warnings is enabled, it is ignored since the
log handler isn't used anymore, and no dump is printed.
Thus, replace the default log handlers with writer functions instead, honoring
backtrace-warnings debug string.
[1] https://gitlab.gnome.org/GNOME/glib/-/commit/fce7cfaf40b6e1e50c9140aa0397f5
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/697>
We considered any ConnectFlag value major than SWAPPED as invalid, while
it's technically not fully true as we need to ensure that the passed
value is respecting the whole flags mask.
In fact, per se SWAPPED|AFTER (> SWAPPED) is a valid value (even if we
don't support the AFTER value).
But this makes the check more future-proof.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
While untracking an object we used to compute it's proto for each signal
we were disconnecting from, while this is not needed when we're just
iterating over all the same owner signals, so let's add few more
functions to compute an object prototype, and repeat the disconnections
in the simplest way we can.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
We used to create a temporary array of signal tracker keys and then to
iterate through them in order to untrack the objects, but the Map's can
be iterated directly so let's just use their native forEach.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.
EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.
The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
For non-MR pipelines, we check for a matching branch or tag name
in mutter. As we use the same naming policy for stable branches
and branch at about the same time, this works generally fine for
branches.
However for tags, it is less unlikely that there is no matching
tag in mutter, in particularly late in a stable cycle when most
changes are translation updates (which are much rare in mutter
than gnome-shell).
Before falling back to main (which is doomed to fail in that case),
try to guess the correct stable branch based on the tag name.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2293>
If we only raise screenshot UI to top, ibusCandidatePopup can still
cover screenshot UI because each time ibusCandidatePopup updates it's
visibility it will raise it to top and this also happens if we open
screenshot UI via keybinding. This commit fixes it by only raising it
above keyboardBox, because keyboardBox is above all entries in modal
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
ibusCandidatePopup actually works as a top chrome because it always
raises itself above top_window_group when updating visibility, so just
initing it as a top chrome instead of initing it below top_window_group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
The overviewGroup's size is currently determined by the coverPane
actor. That actor is only shown during transitions, so we rely on
ClutterFixedLayout including hidden children in its size request.
That odd behavior is about to change, so we need to make sure the
overview still requests the correct size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2351>
