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>
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>
- remove the highlighting js in favour of color definitions, to fix it not really working in light theme or high contrast
- add a bunch of color definitions to set the color of the menu button in the different styles
- drop the border drawing for a separator, to fix visual issues with the high border radius, in favour of a separator element
- change the class names of some things to make it understandable
- bit of overall css tidying
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3554>
- renamed all assets to start with osk- disambiguate them from other keyboard status icons
- updated the design of hide, enter and keyboard layout icons to be more rounded
- new symbolic assets for emoji and delete actions to move away from using 16x16
- updated keyboard scss to use the scalable icon definition
- updated the zwnj asset to align with GNOME icon style
- changed all references to icons in layouts
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3555>
ibus has been mandatory since commit 083d11a032, but it was always
only used at runtime (or during tests). We don't require other
runtime dependencies (like libgdm) at build time either, so stop
checking for ibus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3587>
When the 'text-scaling-factor' key changes and it's set bigger than 1.0,
the corresponding switch is activated in the a11y menu. However, since
commit 946ee936926a0e14fa5f86f62da757bcb581a147, setting the state using
`setToggleState()` also fires the 'toggled' signal, which is I think
correct and intended.
However, that means the GSettings handler for 'text-scaling-factor'
should block that 'toggled' handler when it sets the switch active, as
otherwise the 'text-scaling-factor' is always set to 1.25 when it is
first made bigger than 1.0.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3574>
Almost all switches represent boolean settings, which means we can
use bindings instead of fiddling with signal handlers.
As menu items have a `:sensitive` property, this also deals with
handling keys' writability.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3576>
Updating the accessible state is an internal business of the
class, so making it private is more appropriate.
Besides, it was never called from outside the class since it
was added in 2012, so it's unlikely we'll ever have a use case
for it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3576>
Both popover menus and dialogs can be dismissed with the Escape key,
however the former triggers on key press, while the latter triggers
on key release. As a result, the same key press+release can dismiss
both the command entry's context menu and the run dialog itself.
Fix this by only triggering a key shortcut when a matching key press
was recorded before, which matches how Dialog handles button shortcuts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8132
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3585>
Last cycle, libadwaita added a new Spinner widget whose visuals
we should adapt. It loops extremely slowly though (a framerate
of 60fps would require 3180(!) frames), which means our current
asset-based implementation isn't well-suited for the job.
Instead, reimplement the underlying GdkPaintable as ClutterContent.
This does not only ensure consistency with libadwaita, but also
gives us more flexibility by picking up style information from
the widget the content is attached to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3565>
The magnitude of the noise in the final output scales with:
1.0 - cogl_color_out.a
A fixed value for the magnitude relative to cogl_color_out.a might be
too small for large cogl_color_out.a or too large for small
cogl_color_out.a (or possibly even both).
Compensate for this to achieve constant magnitude in the final output.
The coefficients were determined experimentally as a compromise between
preventing colour banding with dark background content and tolerable
noise with bright background content.
This helps for the issue described in
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7795 .
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3572>
