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>
There's a few things going on here, that unfortunately must
happen in lockstep:
- The gnome-desktop-3.0 dependency gets replaced by gnome-desktop-4
and gnome-bg-4. The code in ui/background.js required minor updates.
- The libnma dependency gets replaced by a libnma4 dependency. The
code in misc/modemManager.js required minor updates.
- The gtk3 dependency is torn down everywhere but tests. Some
missing GdkPixbuf dependencies had to be added to compensate for
its lack.
- gtk_init_check() is no longer called
As a result, we replace a hard gtk3 dependency with a soft gtk4
run-time linking one, only added indirectly through gnome-bg-4
and libnma4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
When the `QuickMenuToggle` was a discrete button, it could be set to
toggle mode, but the inner buttons no longer reacts as expected.
Bind the `toggle-mode` property between the `QuickMenuToggle` and its
contents so they behave as single toggle when enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2664>
Avoid the GTK dependency, and use the common GLib API to store
screenshots in recent files. While at it, give it a better
exec hint than the implicit "gnome-shell %u" GTK added for us,
nobody seems to pay attention to that, but if they ever did
it's better to provide sensible information.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2656>
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>
The FolderView is a subclass of BaseAppView, which already has a
full-blown SwipeTracker attached to it. So no need to add another
PanGesture on top, the SwipeTracker will handle it for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2318>
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>
Menu toggles are currently regular toggles with an additional
arrow button. This allows for a simpler implementation, but
has downsides with regards to keyboard navigation and hover
feedback.
To make it more obvious that the two parts of the menu toggle
perform different actions, change the overall structure of the
toggle to *contain* a regular toggle and the menu button.
That way each element uses its own hover effect, and shows up
in the keynav focus chain.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5964
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2632>
Testing the greeter UI in nested has been broken for a long time
now, because the backend isn't ready yet when we try to push a
modal (via the screen shield).
As running nested is only relevant for development and testing,
working around the issue rather than fixing it properly seems
fine, so do just that and slightly delay startup when testing
the greeter UI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2573>
This is meant to let perf tests initialize themselves earlier than they
would otherwise run.
This allows them to setup the necessary dependencies, e.g. create
test monitors or similar actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
When we unmap, the child widgets have already been destroyed, so we
shouldn't try to. To detect this, delete the references we keep to them
on destroy, and null-check the hide call.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
The cached work area, which is the work area of the primary monitor,
effectively depends on two properties - the (global) work area and the
primary monitor - and we are only tracking changes to one of them. Also
track monitor changes to also cover the second case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
Doing it ourselves in the shutdown handler in layout.js means we won't
risk reacting to monitor changes that happen after gnome-shell prepares
to shutdown and the signal handler would disconnect itself in case we
used `connectObject(..)`.
This will currently never happen, but in the future perf tests will be
able to create virtual monitors for testing purposes, and they might get
destroyed during the shutdown procedures, causing us to react to them
when we shouldn't.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
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>
