| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The earlier commit to change the wording missed the new additions.
Change those too.
Related: #107
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Those device types that exist in upower (and gnome-bluetooth) don't have
a user-friendly precise name that we could use to show in the
notification so fallback to the generic name instead.
eg. a "Wearable" could be a watch, or a number of other devices, but
end-users don't know what a "wearable" is in Bluetooth parlance.
|
| |
|
|
|
| |
Including headphones, headsets and speakers, as well as game
controllers, touchpads and generic Bluetooth devices.
|
| |
|
|
|
|
| |
Both are correct, but the former is harder to parse.
Closes: #107
|
| |
|
|
|
| |
The critical and low power notification titles got merged, so no need to
comment on that.
|
| | |
|
| |
|
|
|
| |
And re-write all the translator strings to clarify which strings are
notification titles/bodies and give more context as to what they mean.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Power notifications for more than a dozen device types were empty as we
only handled a set list of device kinds with no fallback at all.
Closes: #607
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
With newer device types (such as phones and tablets) being used
in GNOME, assuming that a device with more than two power sources,
e.g: battery and current, is a laptop might not be accurate.
Fix that by using a more general and already tranlated string
in all cases.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(cherry picked from commit 714f877925d2add4ec92f5018b922adb3004a148)
|
| |
|
|
|
|
|
|
|
|
| |
Now that we respect the "dim when idle" setting[1], dim quicker to try
and save more power. 4/5 of the timeout to the screensaver was always a
bit too undecided as a fraction, even when using the dimming as a
warning that the screen was going to go to the screensaver (see commit
7bc750a5).
[1]: Except in power-saver mode where we always dim aggressively
|
| |
|
|
|
|
|
| |
The dim screen settings in the UI was not well respected as it only
worked on discharging laptops.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As done on other platforms, aggressively dim the screen after a
short period when the user has selected to enter power saver mode.
The same aggressive screen dim will be used if the battery is low and
power-profiles-daemon is not available. If it is available, then it
fixes a screen dim happening when the battery was low which might
have been unwanted.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/232
Prior art:
https://support.apple.com/en-us/HT205234
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Sometimes the test_legacy_brightness_rounding seems to fail, in rare
cases with the brightness file being empty. This is possible in busy CI
environments due to the short time window (<= 200ms) and because the
script first truncates the file.
Increase the timeout in order to avoid such a CI failure. Note that
writing the update atomically is not really feasible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Xserver itself is capable of terminating itself once all X11 clients
are gone, yet in a typical full session, there are a number of X11
clients such as gsd-xsettings running continuously.
Those always-running clients will prevent the Xserver from terminating,
because the actual number of X11 clients will never drop to 0.
Use XFixes ClientDisconnectMode to inform the X11 server that it can
terminate even if gsd-xsettings is still running.
That will allow Xwayland to terminate automatically once regular clients
have quit.
On plain Xorg servers, the lifetime of the session is usually tied to
the session manager or window manager, and this change will have no
effect.
|
| |
|
|
|
| |
libXfixes 6.0 provides the new ClientDisconnectMode that clients can
use to declare themselves as to-be-terminated.
|
| |
|
|
|
| |
This helped me to find a subtle bug in the code.
I hope that it will help me in the future, too.
|
| |
|
|
|
|
|
| |
The version of USBGuard we targetted for the initial release had a bug:
https://github.com/USBGuard/usbguard/pull/355
Since this is fixed now, we can remove our workaround and use the
correct value.
|
| |
|
|
|
| |
I feel that this makes the device id less magic, despite it being stored
in the manager sometimes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should make it a bit more safe, because the device will not be
authorized before the screen is actually locked. Before, the device
would be authorized and then it asks for the screen to be locked.
This leaves a small window where the device could interact with the
unlocked session. I don't think it is relevant in practice, though.
Anyway, it is semantically more correct to authorize after the screen
has been locked.
This change brings an unfortunate indirection of arguments,
i.e. you have to place the id in the manager structure.
This feels clunky and should be revised.
We should also handle the failure case a bit more gracefully, I think. For
example, show a notification about the device that we wanted to
authorize, but couldn't.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The data is coming in from the outside, so it is untrusted. We check for
the size of the variant, because otherwise we might crash at runtime,
since g_variant_get_child might leave variables, i.e. GVariantIters,
uninitialised (NULL) which then causes g_variant_iter_loop to crash,
since it doesn't check for NULL.
The check for g_variant_n_children is arguably ugly, because
g_variant_get_child will eventually perform that check.
So we focus on the returned NULL in case of g_variant_get_child_value
or, in case of g_variant_get_child, whether the memory has not changed.
The documentation is, for my taste, not as clear as it could or should be.
It mentions that it is "an error" to provide an index higher than what
the GVariant contains. But it doesn't mention how it communicates that
error nor how to deal with it.
|
| |
|
|
|
|
| |
Somehow, I get two notifications on my lockscreen. Since I don't know
where two notifications come from, I try to find out how many we
actually set in our code.
|
| | |
|
| | |
|
