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>
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>
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>
