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>
The DBus PreparingForSleep property on org.freedesktop.login1.Manager
does not trigger PropertyChanged signals, leading to wrong values due to
gdbus caching. In most cases it would have always been false.
Additionally it was not included in the XML interface description file
included in gnome-shell. So it was actually undefined.
Since this property is used in _calculateUserStateFromLogind() to
determine that a user is not active when closing the lid on a laptop,
the user was considered still active.
Fix this by storing the "start" argument from the PrepareForSleep signal
instead of trying to read from the property.
Fixes: 6a43b6f55 ("timeLimitsManager: Store screen time state on suspend/resume")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3679>
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 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>
Defining default apps as serialized GVariants isn't very human-friendly,
which likely contributes to the fact that the lists are in parts horribly
outdated (Books! Cheese! Screenshot! gedit!).
Instead, generate the lists at build time from simple text files, which
should be much easier to update.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
Using the user object at `/org/freedesktop/login1/User/self` is
convenient, but has the caveat that login1 does not emit the
`PropertiesChanged` signal for the object.
That is indeed logical, as for signal emissions there is no
sender that can be used to resolve `self`.
The new TimeLimitsManager depends on change notifications for
user properties, so stop using the `self` shorthand and instead
create the User proxy for the user's UID.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
Most of the function is already asynchronous, except for the
initialization of the returned proxy. gjs' D-Bus wrapper gained
some convenience API a while ago that makes this trivial enough,
so use it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
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>
Unlike for plain JS Errors, the `message` property of GLib.Errors
is read-only, so the intent to replace it with a nicer message
triggers an Error itself.
We could create a new GLib.Error with the changed message instead,
but as it turns out, none of the parse errors contain the technical
prefix we want to strip out, so we can simply drop the special-casing
altogether.
This is also consistent with `spawnCommandLine()`, which never
had special treatment of parse errors.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8146
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3593>
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>
There are cases when we want to mark an animation as required. For
example, we want the "Locate Pointer" animation to work even when
the animation is marked as disabled. Take this into account when
adjusting the animation time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
The return value currently indicates whether the request was
successful, namely `setCompletionEnabled(false)` will return
`true` if completions were successfully disabled.
However the only caller that uses the value uses it to indicate
whether completions were enabled.
Given that nothing else uses the value, change the meaning to
match the caller, and indicate whether completions are enabled
after the call returns.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3439>
The portal login window uses WebKit, which is a security-sensitive
component that not all vendors want to support.
Support that case with a build option, and update the captive
portal handler to use the user's default browser if the portal-helper
is disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
These changes will be used by the next commit when displaying a
conflicting session dialog.
session-removed signal will be used to close the conflicting session dialog
if it's not needed anymore.
getSession method will be used when a session is opened, to check if
there's already a conflicting opened session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3134>
The ibus-typing-booster IM module is already meant to do the "right"
thing when the IBus.Capabilite.OSK hint is passed to the IM. We do
already honor that hint (commit 23bfd08b3c9), and ibus-typing-booster
has been doing this for a reasonably long time (first release seems
to be 2.19.9 dated 2 years ago, current is 2.24.12).
Drop this mangling of foreign settings, and let ibus-typing-booster
figure out the optimal configuration given the presence of an OSK.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
