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>
This fixes a bug which happens if screen time limits are *disabled* and
the history file
(`~/.local/share/gnome-shell/session-active-history.json`) is missing
when gnome-shell is started.
If so, the code would previously have incorrectly called
`this._stopStateMachine()` on startup, even though the state machine
wasn’t running. This adds a fake transition from ACTIVE to INACTIVE to
the history file.
If the user later (that day) enables time limits, the code assumes that
they were active from the start of the day through to that fake
transition, which is possibly sufficient time to reach the user’s limit
already. This results in the screen immediately being made greyscale as
the limit has apparently been reached.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8155
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3597>
This implements wellbeing screen time limits in gnome-shell. It depends
on a few changes in other modules:
- New settings schemas in gsettings-desktop-schemas
- A settings UI in gnome-control-center
- User documentation in gnome-user-docs
It implements the design from
https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png.
The core of the implementation is `TimeLimitsManager`, which is a state
machine which uses the user’s session state from logind to track how long
the user has been in an active session, in aggregate, during the day. If
this total exceeds their limit for the day, the state machine changes
state.
The user’s session activity history (basically, when they logged in and
out for the past 14 weeks) is kept in a state file in their home
directory. This is used by gnome-shell to count usage across reboots in
a single day, and in the future it will also be used to provide usage
history in gnome-control-center, so the user can visualise their
historic computer usage at a high level, for the past several weeks.
The `TimeLimitsDispatcher` is based on top of this, and controls showing
notifications and screen fades to make the user aware of whether they’ve
used the computer for too long today, as per their preferences.
Unit tests are included to check that `TimeLimitsManager` works, in
particular with its loading and storing of the history file. The unit
tests provide mock implementations of basic GLib clock functions, the
logind D-Bus proxy and `Gio.Settings` in order to test the state machine in
faster-than-real-time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/130
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
