From some testing on a full session with break reminders enabled, it
seems that it’s possible to break the stacking order of the lightbox
actor if the user continues to interact with the session while it’s
visible (for example, while they’re supposed to be taking a movement
break).
Rather than try and work out what’s going on with the lightbox here, it
seems more robust to switch to using a Clutter effect, like we did with
the screen time UI (in `timeLimitsManager`). Then the effect can be
applied to the main UI group, and doesn’t depend on a separate actor
being placed in the right place in the scene graph.
So, remove the lightbox, and instead add a
`ClutterBrightnessSaturationEffect`, and use its brightness property to
fade the screen slightly while in breaks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
This makes the buttons on the ‘break overdue’ notification match those
on the ‘time to take a break’ notification. This makes more sense than
showing no buttons on the former, because it leads on from the ‘time to
take a break’ notification after a short wait.
By adding a ‘Take’ button it gives the user a path to acknowledge that
they are starting to take their break, rather than having to let the
session idle.
The ‘break overdue’ notification wasn’t on the original design[1], which is
probably why its buttons got overlooked.
[1]: https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3656>
This avoids the race between systemd emitting the `prepare-for-sleep`
signal, gnome-shell then starting to write the screen time data to disk,
and systemd suspending the hardware.
The race isn’t so much of an issue if the suspend succeeds (if
gnome-shell loses, the data will still get written out when the machine
resumes), but it’s slightly problematic if the machine loses power while
suspended, as that means the latest screen time data is lost.
Includes significant suggestions from Florian Müllner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
There are two main changes in this commit:
* Listen to the `prepare-for-sleep` signal from `LoginManager`, which
is emitted just before suspending and just after resuming. When the
signal is received, update the user’s screen time state (active or
inactive), add a transition if necessary, and save the screen time
history if necessary.
* Factor the `preparingForSleep` property of `LoginManager` into the
user’s screen time state, meaning that the user will be considered
inactive between the system going for suspend and coming back from
resume.
The rest of the changes in the commit are boilerplate to allow for this
functionality to be unit tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
When trying to connect to a network from gdm, it doesn't make sense to query
secrets from the gdm user since it's a system user.
Furthermore, gdm runs an isolated dbus-session per gnome-shell instance
(for multi-seat setups). Instead, gnome-keyring-daemon is started by systemd
and so it registers on the _main_ dbus session of the gdm user session.
Then, gnome-shell tries to dbus-activate another gnome-keyring-daemon on its
isolated bus, but gnome-keyring-daemon refuses to start as it sees another
instance already running, exposed at $XDG_RUNTIME_DIR/keyring/control.
After a 25s timeout, gnome-shell aborts the request without ever prompting
for a new password.
Because it is both problematic and pointless to query secrets in this case,
let's avoid it altogether and just prompt the user for the network password.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3646>
We currently create the default folder with the corresponding
app list, regardless of whether the apps are actually part of
the default install or not.
This matters when a user explicitly install such an app later,
as it will be hidden away in the folder rather than appended
to the app grid as expected.
To avoid that, only add currently-installed apps to the folder
when creating it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
Defining default apps as serialized GVariants isn't very human-friendly,
which likely contributes to the fact that the lists are in parts horribly
outdated (Books! Cheese! Screenshot! gedit!).
Instead, generate the lists at build time from simple text files, which
should be much easier to update.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
When there are 3 or more windows in WorkspaceLayout, showing or hiding
window preview overlay in some certain orders could cause
inconsistencies in windows' vertical arrangement.
Let's take window A, B, C as an example. Initially, A is above B and B
is above C in workspace layout like this: A -> B -> C.
After opening activities, user could:
1. Move cursor to B preview, which would move B above all in layout:
B -> A -> C
2. Move cursor from B to C preview. When C's showOverlay() is called
before B's hideOverlay(), _restack() would move C above all and don't
change B's arrangement:
C -> B -> A
3. Finally, move cursor away from C's preview:
B -> A -> C
In this case, when user closes Activities, they would see window
stacking wrong for a while.
This commit adds some extra logic in _restack, checking the
_stackAbove's _stackAbove when this._stackAbove._overlayShown is true.
Though it's still not guaranteed to be always consistent as there could
be several WindowPreview with _overlayShown as true if pointer moves
really fast, this helps avoid glitches in many cases.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4638.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3460>
Using the user object at `/org/freedesktop/login1/User/self` is
convenient, but has the caveat that login1 does not emit the
`PropertiesChanged` signal for the object.
That is indeed logical, as for signal emissions there is no
sender that can be used to resolve `self`.
The new TimeLimitsManager depends on change notifications for
user properties, so stop using the `self` shorthand and instead
create the User proxy for the user's UID.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
Most of the function is already asynchronous, except for the
initialization of the returned proxy. gjs' D-Bus wrapper gained
some convenience API a while ago that makes this trivial enough,
so use it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
The new design requires that other messages and groups are faded when the user
has a group expanded. This introduces a new GLSL shader to provide the
desired effect. The new shader is used for the already existing scroll
fade and the previous one is removed. The two fades need to work together to
ensure that resulting fade looks good.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
We need to track message order separate from the widget children order,
because of how notification groups will add a cover over other messages
when a notification group is expanded that will prevent interaction with
any message other then the expanded notification group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message grouping by source we need more control over the list of
messages to reflect this change rename the MessageSection to
MessageView. Message from different sources will be added to the
MessageView directly in a future commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message/notification grouping by source we need more control over
each single message therefore in a future commit the
MessageListSection will contain all messages directly instead of having
a separate section for different source (notifications and media).
The lost NotificationSection and MediaSection will be readded in a
future commit as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
Support the new `banner-message-path` and `banner-message-source`
settings, which allows loading the banner message from a path
instead of GSettings. This is mainly useful for `/etc/motd` and
similar mechanisms, to show the same message for both graphical
and non-graphical logins.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3558>
