This avoids the race between systemd emitting the `prepare-for-sleep`
signal, gnome-shell then starting to write the screen time data to disk,
and systemd suspending the hardware.
The race isn’t so much of an issue if the suspend succeeds (if
gnome-shell loses, the data will still get written out when the machine
resumes), but it’s slightly problematic if the machine loses power while
suspended, as that means the latest screen time data is lost.
Includes significant suggestions from Florian Müllner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
There are two main changes in this commit:
* Listen to the `prepare-for-sleep` signal from `LoginManager`, which
is emitted just before suspending and just after resuming. When the
signal is received, update the user’s screen time state (active or
inactive), add a transition if necessary, and save the screen time
history if necessary.
* Factor the `preparingForSleep` property of `LoginManager` into the
user’s screen time state, meaning that the user will be considered
inactive between the system going for suspend and coming back from
resume.
The rest of the changes in the commit are boilerplate to allow for this
functionality to be unit tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
When trying to connect to a network from gdm, it doesn't make sense to query
secrets from the gdm user since it's a system user.
Furthermore, gdm runs an isolated dbus-session per gnome-shell instance
(for multi-seat setups). Instead, gnome-keyring-daemon is started by systemd
and so it registers on the _main_ dbus session of the gdm user session.
Then, gnome-shell tries to dbus-activate another gnome-keyring-daemon on its
isolated bus, but gnome-keyring-daemon refuses to start as it sees another
instance already running, exposed at $XDG_RUNTIME_DIR/keyring/control.
After a 25s timeout, gnome-shell aborts the request without ever prompting
for a new password.
Because it is both problematic and pointless to query secrets in this case,
let's avoid it altogether and just prompt the user for the network password.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3646>
* Remove obsolete apps
* Add new core apps
* Deduplicate apps which were in both the grid and a folder
* Split system tools out of the utilities folder
* Rearrange the dash a little
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3642>
