4 Commits

Author SHA1 Message Date
Philip Withnall
72cb52e743 timeLimitsManager: Hide ‘limit reached’ notification when reset
If the user changes their daily limit setting so that they’ve no longer
reached their limit, remove the ‘limit reached’ notification from the
message tray, if it’s still there, when disabling greyscale mode.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8164
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3603>
2025-01-20 19:05:58 +00:00
Philip Withnall
c890a2f1e3 timeLimitsManager: Reset screen time if daily limit is changed
If the limit for the day had already been reached, the
`timeLimitsManager` was not resetting the screen time state if the daily
limit setting was then changed (and increased).

Fix that, and add a unit test for it.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8164
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3603>
2025-01-20 19:05:58 +00:00
Philip Withnall
08b06acc4c timeLimitsManager: Only stop the state machine if it’s already running
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>
2025-01-15 17:58:15 +00:00
Philip Withnall
212e098da1 timeLimitsManager: Add new state machine for screen time limits
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>
2025-01-13 14:24:02 +00:00