Rename the following strings (and use header capitalization):
- "When on battery power" to "On Battery Power"
- "When plugged in" to "When Plugged In" (in the Automatic Suspend
dialog too)
Reference 1bb482ed19
Use a single CSS file for the entire panel.
This will make easier to set custom style
for specific widgets without having to create
a bunch of CSS files for each widget type.
Using the systemd-hostnamed chassis-type to detect when running on
"tablet", "handset", or "watch" and setting a more reasonable list
of suspend time options for them.
This reverts commit 4a0d924afd.
There are some rough edges to be polished before this is ready for
prime time.
UPower battery health capacity reporting can often be inconsistent
across vendors, and we don't want to expose unreliable information
on the UI without proper sanitization.
As described in #2554, it would be useful to be able to see battery health information
such as charge capacity in Settings. This commit implements the proposed design for
battery health information, adding this functionality to the power panel.
Closes#2554
As described in #2521, the automatic suspend row is currently shown
when Settings is running in a VM, in which case it has no effect.
This commit checks whether Settings is running in a VM and disables
showing the automatic suspend row in this case, as is done for the
Suspend/Hibernate rows. This prevents the user from being shown a
useless row in the power panel.
Closes#2521
In some cases, it was possible for a profile to be set (directly, or
through a hold) even though it wasn't supported. Don't assert in those
cases.
Closes: #1504
Ambient light sensors can be quite sensitive and the LightLevel
property might be changing very often. That has two undesired
consequences:
* The `als_enabled_state_changed` callback gets constantly called
due to a change in a property which it does not care about, as
only `HasAmbientLight` is relevant. Therefore, limit the code
execution to when something needs to be changed.
* During debugging, the terminal gets spammed with "ALS enabled: on/off"
messages.
From https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1020#note_1211728
"
They are out of place - fine-grained control over brightness isn't what the
power settings are for. As a result, they confuse the settings overall.
In both cases we have alternative controls, through keyboard hot keys or
through the shell's screen brightness slider.
"
It's pretty clear from their experiences on smartphones that our users
know that Wi-Fi and other wireless technologies use enough battery that
turning them off is a power saving move.
The switches and text were also pretty confusing as we would be turning
"off" the devices to turn "on" the power saving.
A logic error meant that the power profiles info boxes container
would not be shown if there wasn't a "degraded" performance as well.
Spotted by Allan Day
Reword the lap mode info message slightly as the performance mode might
not have been what the user requested, but the warning should stay until
cleared nonetheless.
Applications can request that power-profiles-daemon "hold" a particular
power profile for the duration of a task or event, such as launching a
taxing application, or saving power because of low battery.
Show those holds in the same type of info boxes we already use to show
"degraded" performance.
See https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/merge_requests/46
gnome-control-center/panels/power/cc-power-panel.c: In function ‘keynav_failed_cb’:
gnome-control-center/panels/power/cc-power-panel.c:892:50: warning: statement with no effect [-Wunused-value]
892 | direction == GTK_DIR_UP ? GTK_DIR_TAB_BACKWARD : GTK_DIR_TAB_FORWARD;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
This drops the ability to loop through the page but significantly
simplifies the code. I think this is a good tradeoff as looping is a
rather unexpected behavior.
When opening the Power panel, and if power-profiles-daemon isn't already
started, we'll be autostarting it, making it send signals about all the
changed properties, including "PerformanceInhibited" even if we
don't have a Performance row.
Ignore the property change if we don't have a row for it rather than
asserting.
#0 0x00007f73916bc292 in raise () from /lib64/libc.so.6
#1 0x00007f73916a58a4 in abort () from /lib64/libc.so.6
#2 0x00007f7393203ccc in g_assertion_message.cold () from /lib64/libglib-2.0.so.0
#3 0x00007f739325f22f in g_assertion_message_expr () from /lib64/libglib-2.0.so.0
#4 0x000055a4099e28ae in performance_profile_set_inhibited (self=0x55a40b37e320, self=0x55a40b37e320, performance_inhibited=<optimized out>) at ../panels/power/cc-power-panel.c:1366
#5 power_profiles_properties_changed_cb (self=0x55a40b37e320, changed_properties=<optimized out>, invalidated_properties=<optimized out>, proxy=<optimized out>) at ../panels/power/cc-power-panel.c:1425
#6 0x00007f7393332c2f in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#7 0x00007f739334eea6 in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0
1362 {
1363 CcPowerProfileRow *row;
1364
1365 row = self->power_profiles_row[CC_POWER_PROFILE_PERFORMANCE];
1366 g_assert (row != NULL);
1367 cc_power_profile_row_set_performance_inhibited (row, performance_inhibited);
1368 }
