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
2023-08-09 15:10:38 +00:00
2024-08-28 19:49:45 +00:00
2024-01-25 16:53:36 +00:00
2023-08-06 13:02:49 +02:00
2024-10-09 11:36:15 +00:00
2023-04-21 18:28:32 +00:00
2024-06-27 16:39:08 +02:00
2014-01-08 04:35:14 +07:00
2024-09-14 17:17:32 +02:00
2024-05-28 17:31:15 +00:00

GNOME Shell

GNOME Shell provides core user interface functions for the GNOME desktop, like switching to windows and launching applications. GNOME Shell takes advantage of the capabilities of modern graphics hardware and introduces innovative user interface concepts to provide a visually attractive and easy to use experience.

All interactions with the project should follow the Code of Conduct.

Supported versions

Upstream gnome-shell only supports the most recent stable release series, the previous stable release series, and the current development release series. Any older stable release series are no longer supported, although they may still receive backported security updates in long-term support distributions. Such support is up to the distributions, though.

Please refer to the schedule to see when a new version will be released.

Reporting bugs

Bugs should be reported to the issue tracking system.

The GNOME handbook has useful information for creating effective issue reports.

If you are using extensions, please confirm that an issue still happens without extensions. To properly disable extensions you can use the extensions-app and then restart your session. Disabling extensions without a restart is not sufficient to rule out extensions as the cause of a bug. If an issue can only be reproduced with a certain extension, please file an issue report against that extension first.

Please note that the issue tracker is meant to be used for actionable issues only.

For support questions, feedback on changes or general discussions, you can use:

Feature requests

gnome-shell is a core compoment of the GNOME desktop experience. As such, any changes in behavior or appearance only happen in accordance with the GNOME design team.

For major changes, it is best to start a discussion on discourse and reach out on the #gnome-design matrix room, and only involve the issue tracker once agreement has been reached.

In particular mockups must be approved by the design team to be considered for implementation.

For enhancements that are limited in scope and well-defined, it is acceptable to directly open a feature request.

When in doubt, it is better to ask before opening an issue.

Contributing

To contribute, open merge requests at https://gitlab.gnome.org/GNOME/gnome-shell.

It can be useful to first look at the GNOME handbook.

If a change likely requires discussion beyond code review, it is probably better to open an issue first, or follow the process for feature requests. Otherwise, creating a separate issue is not required.

The following guidelines will help your change to be successfully merged:

  • Keep the change as small as possible. If you can split it into multiple merge requests, please do so.
  • Use multiple commits. This makes it easier to review and helps to diagnose bugs in the future.
  • Use clear commit messages following the conventions.
  • Pay attention to the CI results. Merge requests cannot be merged until the CI passes.

There's also a small guide for newcomers with a few more basic tips and tricks.

Documentation

API Reference

  • Meta: Display server and window manager
  • St: Shell toolkit
  • Clutter: OpenGL based scene graph
  • Shell: Non-ui shell objects and utilities
  • See the mutter page for additional documentation

License

GNOME Shell is distributed under the terms of the GNU General Public License, version 2 or later. See the COPYING file for details.

Description
Languages
C 49.2%
JavaScript 47.4%
SCSS 1.4%
Meson 0.8%
Python 0.6%
Other 0.4%