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>
If we are getting purpose hint changes while the language switcher is popped
up, this likely means the purpose hint was actually triggered by the key
focus change induced by the language switcher popping up.
In this case, we on one hand would like to preserve the state that applied
before thise focus change, and on the other we very much want to avoid the
keymap change that would forget about the keys being pressed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6066
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2534>
We assign (disambiguated) device names every time a device is added
or removed, and store the name on the corresponding menu item.
However menu items are only created when the device should be shown,
not necessarily when it is added (unplugged ethernet cable, ongoing
initialization, ...).
Fix this by tracking device names separately from device items, and
set the name on newly created items.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6040
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2529>
GDBusProxy transparently handles the remote object appearing and
vanishing. It is therefore not an error if the service is not
running at the time the proxy is initialized, so we proceed and
try to read the list of profiles which is null in that case,
resulting in (harmless but annoying) warnings.
Avoid this by only reading the initial list of profiles if the
service has a name owner.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5992
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2518>
Consider the existing input sources MRU only valid if it contained
more than one element to pick from. Fixes the following situation
with initial-setup sessions:
- Initial setup Session starts, with several input sources already
configured ("us" between them)
- InputSourceManager initializes, only the default "us" keymap is
available
- MRU list is constructed, "us" is picked
- InputSourceManager catches up with session configuration, the
other extra sources are added
- MRU list is reconstructed, "us" is already the most recent
- Session ends up with "us" picked, regardless of its position in
the list, and no MRU existing prior to startup
If we consider the intermediate single-element MRU list invalid,
it is still possible to pick the best default source between all
the configured ones (the one that was put first in the list,
basically), after initialization is complete.
But also, it is unnecessary to have if there is a single source to
pick from. After the sources list has two elements or more, the
MRU list will become effective and preserved during changes to
the available sources.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5873
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2495>
In older versions of GNOME, when a menu was used for Bluetooth devices,
we tried to avoid showing the Bluetooth menu to folks who didn't use
Bluetooth.
This kept causing problems as the menu would disappear if no
devices were setup and the platform "airplane mode" removed the
Bluetooth device from the USB bus, making it impossible to detect
whether a Bluetooth device existed, compared to a user unplugging a
removable Bluetooth device.
Closes: #5749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2488>
When updating the MRU sources if there was no prior MRU, we want
to go with the unmodified list of sources in visibility order.
However iterating over object properties happens in an undetermined
order, so the initial MRU list ends up picking a value at random.
In order to prefer the sources list in the same order than they
appear in the menu if there was no prior MRU, order the keys
when accessing it and building the initial list of sources.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5873
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2487>
If a device has multiple connections set up, then at most one of
those can be active at a time, which is why they are presented
as radio items.
In contrast, VPN connections are not mutually exclusive, each can
be turned on or off independently. Setting :radio-mode on them
currently means that VPN connections can be activated, but never
disabled.
So instead of abusing the :radio-mode property to give VPN items
the UI we want, use regular items that reflect the desired behavior
and explicitly set up the UI the way we want.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2426>
We got a shiny new screenshot UI last cycle, but only relatively
obscure ways of launching it: Keyboard shortcut or overview search.
The new quick settings provides us with a natural place to expose
the functionality more prominently, and at the same time reduce
the emptiness of the top row, in particular on systems without a
battery and when locked.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
When we aren't showing the power toggle (read: on systems without
a battery), all items in the top are located on one side. Address
this by "moving" the spacer between "Settings" and "Screen Lock"
in that case to balance items a bit better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
The quick settings code was first developed in an extension, which
meant it made sense to maintain compatibility with GNOME 42 and not
use the new :icon-name convenience property.
There is no good for sticking with that for GNOME 43 as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
