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>
In order to keep the test code brief, all expected times and dates are
written as ISO 8601 strings in the test code, and use `Z` to specify UTC
(again, to keep things brief).
If the test is run under a significantly different timezone, the
end-of-day timestamp changes significantly, as it’s calculated by the
code-under-test using the local timezone.
Avoid that issue by requiring the `timeLimitsManager` tests to always be
run in UTC.
The previous failure could be reproduced by running `TZ=Europe/Madrid
meson test -C /opt/gnome/build/gnome-shell timeLimitsManager --verbose`
— the test for “tracks a single day’s usage early in the morning” would
fail.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3605>
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>
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>
Not until we've waited for leisure can we make precise assumptions about
otherwise animated actors sizes and positions, so do that before
checking fittsiness.
This should fix the flakyness of the fittsy test case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3398>
Jasmine[0] is a popular testing framework for javascript, which
gjs itself has used in a heavily customized form for its own
unit tests for years.
It's far superior to the very rudimentary `jsUnit` module that
is still included with gjs, and the jasmine-gjs project provides
a general-purpose wrapper for gjs apps.
Set up the necessary build infrastructure to run unit tests
through jasmine. That allows for existing unit tests to be
ported one-by-one.
[0] https://jasmine.github.io/index.html
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
We build a small run-js-test executable so tests run in a
similar environment as gnome-shell, and then wrap it with
a generated script that provides environment variables like
GI_TYPELIB_PATH.
This is more complicated than it needs to be, we can just as
well set up the typelib search path from the runner and pass
in the environment via meson.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
This drops all subclasses of `MessageTray.Source` that were used to
display system notifications. Now the `Source` returned from
`MessageTray.getSystemSource()` is used.
Ensure also that properties and methods that where set on the `Source`
are moved to the `Notification` object itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3156>
Since commit c570011 dropped the `with` statement, this bit of
the test has only checked for writes to a specific variable
in the file.
There is no direct replacement for `with` here, the best we can
do (I think) is comparing property names on the global objects
before and after the `eval()` call.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3132>
This produced the following warning:
```
DEPRECATION: Project uses feature that was always broken, and is now
deprecated since '1.3.0': str.format: Value other than strings,
integers, bools, options, dictionaries and lists thereof..
```
The resulting value of `SHELL_BACKGROUND_IMAGE` was indeed bogus, not
containing a proper file path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3123>
Unit tests currently load shell sources directly from the
filesystem.
This is currently blocking generated sources - namely config.js - to
ESM, because a relative import from the source dir will fail to
locate the file in the build dir.
Address this by using the same GResource as gnome-shell instead of
direct filesystem access, as the resource will always include all
sources files at the expected location.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
Overriding vfuncs can be useful, in particular when we convert
to ES modules, and exported symbols cannot easily be swapped out.
Adapt overrideMethod() to work correctly in that case as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2809>
Removes the init() function in favor of executing all environment
changes when the file is imported.
Additionally ports all unit tests using imports.gi.environment.init() to
use the updated module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
