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>
Internally in gnome-shell it may be useful to modify the actions
available on a notification while it’s still visible, but without
clearing them all and re-creating them.
Allow that by returning the action object when adding it, and adding a
`removeAction()` method which takes that object and removes it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3251>
If the shift key was pressed, we should switch back to the default level
after the next commit. It seems that this only worked due to a superfluous
signal emission so far (see https://gitlab.gnome.org/GNOME/mutter/-/issues/3448).
When the keyboard is in this "shift" level (note: only "shift", not
"opt+shift" level) without being latched, there are certain events that
should put it back into the default level:
- A normal character key on the OSK being pressed
- A keyval on the extended OSK (eg. TAB key or an arrow key) being pressed
- The backspace key being pressed
- The OSK being hidden
- The user moving focus in the entry
The `_updateLevelFromHints()` function already takes care of updating the
active level after certain kinds of events, we can achieve the desired
behavior by adding a fallback case to that function where it moves the level
back from "shift" to "default".
Since we only want this switch back to the "default" layer as a response to
actual user input, add a `userInputHappened` boolean to
`_updateLevelFromHints()` and don't set that when the application simply
changes its content hints.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
Looks like we currently do the press-and-release dance for keys that specify
both a keyval and the "modifier" action. So when pressing CTRL in the
extended OSK, not only is the CTRL modifier set together with the next key
pressed, but the actual CTRL keyval quickly gets pressed and released,
similar to how we'd do it for the TAB key.
This seems unintentional, as the press-and-release behavior should probably
be specific to keys like TAB, and not apply to modifier keys, so limit that
behavior to only keys without an action specified.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
A lot of keys have no action set. In that case key.action is `undefined`,
but the strict equality check of `action !== null` here will return true and
we'll enter the if-case anyway.
That's quite confusing and was not intended like that, so change the
comparison to a less-strict operator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
When representing the keyboard backlight levels as discrete items,
it is currently not possible to keynav past the first button.
Fix this by bypassing the usual event bubbling and passing key press
events directly to the focus manager, similar to what we do for
popup menu items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3545>
Instead of having the name of the directory be X-GNOME-Utilities. This
also allows translating the name to the user's language. The name is
chose to be different to X-GNOME-Utilities from GNOME Menus.
In the process, also remove the categories. The menu definition from
gnome-menus is not used, and it's not a category that apps list
themselves, so it's completely unused anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3526>
- remove unnecessary dialog type-specific padding, spacing and margin definitions that led to layout to problems
- bump the size of user avatar in authentication dialog
- nest css classes in the sass to better reflect the structure of dialog elements
- sync style of audio device selector with switcher-popup style
- sync text and padding styles with other elements
- fix incorrect button order in audio selection dialog
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7876
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3473>
The Meta keybinding API now exposes the Clutter event to GJS, which was
previously hidden due to it being a gpointer. Since this moves the
binding argument one argument to the right on the GJS side, any code
that was using the binding argument needs to be updated.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3502>
As the keyboard is released asynchronously after setting the ibus
engine, there's a possibility that the `this._reloading` property
changed in the meantime.
To ensure that `holdKeyboard()` and `releaseKeyboard()` are correctly
paired, record the condition in a local variable so that it maintains
its value in the callback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>
When commit ce89b15bb123d made the code async, it did not only
delay releasing the keyboard until after the engine has been
updated, but also the following code that updates the current
input source.
One result is that the current source is now initialized later,
which breaks any code that relies on the source being set.
This affects the login screen in particular (which uses different
`InputSourceSettings` than the regular session): It fails to come
up entirely if the OSK is enabled.
To fix the issue, use a .then() callback to release the keyboard,
instead of blocking all following code with await.
Fixes: ce89b15bb1 ("ibusManager: Use async await instead of callbacks")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7912
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>
We had code to ensure that all the queued messages sent by a PAM module
were shown by waiting some time to give the user time to read them, but
due to a typo this code never executed.
Fixes commit dd97a2589b8b686f273550f3e9e6ce370b25c10d
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3466>
The ripples are used both for the "Hot Corner" animation and for the
"Locate Pointer" animation. The latter one is an accessibility feature
and should always work, even when animations are disabled. Take this
into account.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
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 as marked as disabled. Take this into account when
easing an actor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
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>
When creating a new NM connection they are by default system connections. A
user cannot create them if they don't have the correct polkit permissions
(org.freedesktop.NetworkManager.settings.modify.system).
If a user tried to add a new connection in the drop down menu, then they got
no password prompt and NM logged the following:
[...] audit: op="connection-add-activate" pid=1872 uid=1000 result="fail" \
reason="Insufficient privileges"
This change adds the current user to the user permissions for the new
connection, if the user has no permissions to modify the system connections,
which copies the behavior of GNOME Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3462>
The coordinates are effectively in the windowing system coordinate
space, which when scaling Xwayland, we need to scale these. Do this with
the Meta.Window.protocol_to_stage() function on the focused window,
which handles it correctly for the corresponding windowing system and
configuration.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3458>
