BoxLayout is extremely common, so removing the old `vertical` property
in favor of `orientation` would be very disruptive. Instead, deprecate
it to indicate our intention of removing it eventually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
Using "vertical: false" to express "horizontal" has always been a
bit awkward. While we have stuck to the existing property for a long
time, transitioning to an `orientation` property like in GTK and
Clutter seems better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
It is tightly coupled to the preview, and not meant to be unset
or replaced during the lifetime of the object; size requests
and allocation assume that it exists.
Make that explicit by marking the property as construct-only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
The container is tightly coupled with the preview, and there is
never a need to replace it at a later point. Set it directly
during construction, so the underlying base class can make
this explicit by marking the property as construct-only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
We currently only specify the library to link with when declaring
a dependency, which means that satisfying other requirements like
dependencies or includes is left to the targets.
Move everything required by libshell/libst to the declared dependency,
so other targets only need to care about their own requirements.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
Our code to "forward" `notify` signals from the underlying layout
manager for the `vertical` property broke when ClutterLayoutManager
removed its own `vertical` property.
Property changes via the underlying layout manager should be rare,
but still worth fixing, so explicitly connect to `notify::orientation`
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3613>
This adds a comment to make clear that the Utilities category is
intended to be organized alphabetically by the display name of
the apps (*not* by the desktop file names), and adds comments
with the current display name of each app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3609>
These have (Logs) or previously had (Characters) the
X-GNOME-Utilities category in their .desktop file and so showed
up in the Utilities folder (despite 152faae claiming that the
category was "completely unused"). Characters had the category
removed in
https://gitlab.gnome.org/GNOME/gnome-characters/-/commit/210eb09
in apparent expectation that it would be added to the list, but
it seems it was not.
We could restore consideration of the category, but I guess let's
just list the apps instead? I don't know if any others are
missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3607>
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>
To prevent sporadic shutdown failures:
```
** Message: 17:08:37.707: Shutting down GNOME Shell
(gnome-shell:91892): Gjs-CRITICAL **: 17:08:37.728: Object .Gjs_ui_panel_Panel (0x5b53524fb030), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3601>
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 is mostly for use when testing a nested gnome-shell in a terminal:
terminating it with Ctrl+C from that terminal should give the process an
opportunity to save state on shutdown (such as the screen time limits
history file).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
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 is a `GSource` which is dispatched when the offset of the system
real/wall clock changes with respect to the system monotonic clock. This
can happen when the user explicitly changes the system clock, or when
there’s an NTP sync after a prolonged period offline.
The source can’t tell you *what* the offset change was, just that there
was one.
This will be used in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
