Layout items use the ornament to indicate the active layout, so
their ornament should always be NONE or DOT.
The default is about to change to HIDDEN, so explicitly initialize
the ornament to NONE to keep the current radio item appearance.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Settings no longer exposes a slider for the keyboard brightness,
leaving keyboard shortcuts as the only way of adjusting it.
This is good enough in most cases, because devices with keyboard
backlight usually include corresponding keys on their keyboard.
However for devices without those keys, it would be good for the
settings to be exposed somewhere again. Quick settings seems like
a more appropriate place than "proper" Settings, since it gives
quick access that doesn't require a major focus change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6765
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2820>
Use the new privacy indicator class for the input one and move it next
to the other privacy indicators.
While on it move all privacy indicators to the front, following the
system-status-indicators mockup.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
- spin out all the panel button styling into a drawing mixin
- clean up the styles generally
- make special cases for the clock and non-flat buttons
- contrast fixes for non-flat buttons, fixes#6768
- new stop icon for the screen recording/cast indicators
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2804>
Now that we track apps instead of instances, we can make the menu
items activatable, because the corresponding action is no longer
app specific (like activating a particular tab): We can simply
activate the app, which hopefully will bring it to the foreground
again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
The background apps menu currently tracks instances rather than
apps. That matches the behavior of `flatpak ps` and can be useful,
for example when one particular instance runs out of control.
But as we don't include any information that allows to actually
distinguish between instances, multiple instances appear simply
as duplicated app entries.
Given that a menu is too limited for detailed information, stop
representing individual instances, and track apps instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
When we can't detect a headphone by form factor, we do a string
match on the port name. A match on 'Headphone' isn't less likely
to be valid than a match on 'headphone', so make sure we ignore
capitalization.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2691>
Commit 9d75d777c7 introduced code to hide the subtitle of the
quick setting toggle when it matches the title of the toggle.
That's because NetworkManager tries to make the network names
more palatable on its own, and reports that the name of single
wired networks is "Wired" even if it may have another name.
What that commit failed to account for, however, is that there are
other circumstances where we end up with a subtitle is exactly the
same of the title. For example, when turning off Wi-Fi or mobile
broadband connections.
The behaviour of commit 9d75d777c7 is safe enough to be applied
on other device-backed connections, so do it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2682>
In GNOME OS, due to a misconfiguration, geoclue was configured without
systemd support. In that configuration, geoclue does not install its
systemd .service file (geoclue.service) but it (incorrectly) includes
the following line in its D-Bus service file:
SystemdService=geoclue.service
As a result, when dbus-daemon tried to activate it at gnome-shell's
request, it would fail with:
Unit geoclue.service not found
Then, GeoclueAgent._onGeoclueVanished() would be called, as the
name_vanished_handler passed to Gio.bus_watch_name(). This is consistent
with Gio.bus_watch_name()'s documentation:
> You are guaranteed that one of the handlers will be invoked after
> calling this function.
But that function assumed that this._managerProxy is defined, leading
to:
JS ERROR: TypeError: this._managerProxy is undefined
_onGeoclueVanished@resource:///org/gnome/shell/ui/status/location.js:163:9
Fix this by checking for nullishness of this._managerProxy. (Strictly
speaking, it's undefined rather than being null, but other code in this
file already uses the vaguer '!= null' test, which considers undefined
to be null.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2681>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2660>
gnome-bluetooth clears the list of devices when the adapter goes
away, but we cannot assume that that'll happen when powered down.
We don't want to show a (potentially outdated) list of devices
that cannot be interacted with in that case, so explicitly check
for the active state when returning devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2658>
NetworkManager frequently refreshes the list of available access points.
For some reason this often ends up removing some or all access points
only to add them back in a later refresh later. With the exception of
the currently connected access point, which is never removed.
When all access points of a WirelessNetwork have been removed, it gets
destroyed by NMWirelessDeviceItem::_removeAccessPoint(). This however
does not happen for the currently connected network due to the always
present access point. If this network now happens to consist of multiple
access points, the "unused" NMAccessPoints will get removed and added
in these refreshes, without the WirelessNetwork getting destroyed.
Whenever such an unused access point is added, due to the use of signal
tracking this leaks the NMAccessPoint and SignalTracker until the
WirelessNetwork is destroyed.
However when the NMWirelessDeviceItem is destroyed, for example due to
suspending, it stops tracking access point changes, ensuring that the
condition for the WirelessNetwork being destroyed can not occur anymore.
Even with just two access points, such as can be found in 2.4GHz+5GHz
home routers this issue leaks hundreds of NMAccessPoints and
SignalTrackers per day. As well as a small number of WirelessNetworks
which are also kept alive by the SignalTrackers.
To fix this disconnect from the access point when it gets removed and
destroy all remaining networks when the NMWirelessDeviceItem is
destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2652>
Sandboxed apps that run without a window are detected by the new
background monitoring service, introduced by xdg-desktop-portal.
We have an opportunity to improve the predictability of the desktop
and ensure that application state in transparently reported to users
by showing these apps, and allowing them to closed.
Add a new background apps menu to the quick settings, that is always
added at the bottom of the popover, and has a slightly custom, flat
style applied to it.
Show background-running apps in this menu, and allow closing them
by first attempting to execute the 'quit' action through D-Bus, and
if that fails, sending SIGKILL to the process.
See https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/191
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2624>
Thanks to NetworkManager's connection name disambiguation, it's
pretty common for single wired connections to be named "Wired". This
is fine and what we want almost all times, but in the specific case
of quick settings, we already have a "Wired" string set as title of
the quick settings toggle, so having that as subtitle is reduntant.
Hide the subtitle label (by returning null) when the subtitle of
a wired network matches the title.
Fixes ab10b95d2d
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6369
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2627>
If there is a single connection for a given NMToggle subclass,
use the connection name; otherwise, transform that into '%d
connected'. This is better than the current "Device (counter)"
template, e.g. "VPN (2)", which would give us a quick toggle
with:
VPN
VPN (2)
Change that to e.g.:
VPN
2 connected
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Following the previous commits where we left the quick toggle title
open for the new title scheme, set the titles for all network pills
to what currently is the "default" name.
That means, we pull the device name from Network Manager for devices,
through the disambiguate function, and hardcode 'VPN' for VPN
connections.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Instead of map the currently active items - for whatever they are -
into the quick toggle title, bind it to the subtitle.
This leaves room for setting static titles for device-backed
networks, such as Wi-Fi, Wired, Bluetooth, etc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Device additions/removals are tracked by GvcMixerControl, which
doesn't change when unsetting the stream. So clearing the menu
manually was a workaround, not a fix.
It's also worth noting that I failed to reproduce the original
issue again, so it's possible that we were working around a
pipewire bug that has since been fixed.
This reverts commit 1b62b7ea0a.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2616>
