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>
After an extension is installed, run `glib-compile-schemas` on its
`schemas` directory, if it exists.
This should avoid any endianess-related issues for extensions when
running GNOME Shell on varying architectures.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
This is something that will be used in other places outside the
background code, so let's just define it globally without having to care
about the importing order.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
We include a private hidden .desktop file for evolution's calendar
component, so that we can explicitly open that component when
evolution is configured as the default calendar application.
That's because the evolution developers didn't want to ship
additional .desktop files at the time, but they have since
then included a desktop action that can be used for the same
purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2479>
Switching between the app grid and the window picker in the overview via
gestures results in _gestureEnd() getting called with endProgress !== 0
in both cases, which leads to it calling _showDone(). This then
unconditionally changes the state to SHOWN, which in this situation is
already the current state. Since the previous commit this results in a
warning, so check if we are already in the SHOWN state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
There have been several bugs in the past that caused invalid transitions
of the `shown` state, such as going from `showing` to `showing`. These
cause consecutive emissions of the `showing` signal, which can confuse
other classes such as the search controller which connects to the stage
`key-press-event` on showing and disconnects again on `hiding`. Having
two consecutive `showing` signals will cause it to connect twice, and
only disconnect once when hiding the overview again. This will lead to
key presses getting repeated in the search until the session is
restarted. Because there is no obvious connection to how and when this
issue got triggered, this now adds some validation code that only allows
valid transitions and throws an error otherwise so we get a backtrace of
the code actually causing the problem.
This does not fix the issue(s) causing the invalid state transitions, it
only adds a way of tracking them down.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
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>
Since commit a1d650ce27, window title changes are listened for in the
ShellWindowTracker in order to emit ::tracked-windows-changed when
there are window title changes.
The rest of the things that happen in between (removing the window
from a ShellApp, possibly have it destroyed, and possibly creating a
new ShellApp to re-insert the window) are superfluous and even result
in the altTab switcher popup ending up confused about the applications
available.
Only emit the signal so changes can be followed on D-Bus, but avoid
the ShellApp fiddling otherwise.
Fixes: a1d650ce27 - window-tracker: Emit 'tracked-windows-changed' on title changes
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6385
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2634>
