This doesn’t introduce any functional changes, as
`this._manager.currentBreakType` is set to the value returned by
`this._manager.getNextBreakDue()` when entering `BreakState.BREAK_DUE`.
However, it should make the code a little clearer as now the code refers
to the ’next’ break type rather than the ‘current’ one in the context of
an upcoming break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
The change of settings may have affected when a break is due. In
particular, `this._breakLastEnd` is modified in `_updateSettings()`,
but `this._state` is not modified correspondingly to transition to/from
a `BREAK_DUE` state (if appropriate).
This could be the cause of the `breakDueAgo should be non-negative`
assertion failure from #8280.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Confusingly, the `brightness` property of
`ClutterBrightnessContrastEffect` has type `CoglColor`, but the
`set_brightness()` setter takes a single `float`.
We previously chose to use the property setter everywhere for
consistency (see
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655#note_2369353),
but didn’t realise the types don’t match.
GJS optimises `this._brightnessEffect.brightness = foo` into a call to
`clutter_brightness_contrast_effect_set_brightness()`, which means the
type mismatch between the two results in a warning (see
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280).
So, let’s change from a property setter into an explicit method call to
avoid the type ambiguity, at the expense of a bit of clarity from using
the same method to set the initial value and each property animation
step.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
From some testing on a full session with break reminders enabled, it
seems that it’s possible to break the stacking order of the lightbox
actor if the user continues to interact with the session while it’s
visible (for example, while they’re supposed to be taking a movement
break).
Rather than try and work out what’s going on with the lightbox here, it
seems more robust to switch to using a Clutter effect, like we did with
the screen time UI (in `timeLimitsManager`). Then the effect can be
applied to the main UI group, and doesn’t depend on a separate actor
being placed in the right place in the scene graph.
So, remove the lightbox, and instead add a
`ClutterBrightnessSaturationEffect`, and use its brightness property to
fade the screen slightly while in breaks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
This makes the buttons on the ‘break overdue’ notification match those
on the ‘time to take a break’ notification. This makes more sense than
showing no buttons on the former, because it leads on from the ‘time to
take a break’ notification after a short wait.
By adding a ‘Take’ button it gives the user a path to acknowledge that
they are starting to take their break, rather than having to let the
session idle.
The ‘break overdue’ notification wasn’t on the original design[1], which is
probably why its buttons got overlooked.
[1]: https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3656>
This implements health break reminder support in gnome-shell. It depends
on a
few bits and bobs from other modules:
- New settings schemas in gsettings-desktop-schemas (released in
47.beta, which Mutter already depends on)
- 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 `BreakManager`, which is a state
machine which uses the Mutter `IdleMonitor` to track whether the user
is, or should be, in a screen time break.
The `BreakDispatcher` is based on top of this, and controls showing
notifications, countdown timers, screen fades, the lock shield, etc. to
make the user aware of upcoming or due breaks, as per their notification
preferences.
Unit tests are included to check that `BreakManager` works. These
provide mock implementations of basic GLib clock functions, the
`IdleMonitor` 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/3251>
