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 }
If you can't suspend/hibernate or on a mobile device or VM then the battery
percentage is control is supposed to be shown.
The parent widgets are hidden though, so this doesn't work.
Always show the parents, as all branches show something here.
This was added in 6a65dcf693.
Calling gtk_css_provider_load_from_resource() twice will remove any
already loaded resource instead of adding the new CSS with the old. Load
each CSS individually instead.
Fixes: f1bcaf1fbc
It seems this was added in ee36b0df91, but the `status` variable has
been unused since a9683772d9 (committed in 2012).
Seems safe to remove if it's been unused since 2012.
`set_primary()` and `add_primary()` had a lot of redundant code. This
unifies them, and moves them to a custom widget called `CcBatteryRow`.
This also decreases the somewhat excessive size of `cc-power-panel.c`,
and makes it easier to see the layout of widgets, now that it's
specified in xml.
Before this, `warning-battery-offset` was set to `0.03` for a "primary"
battery, and `0.05` otherwise. I expect this is a bug, so I've changed
both to `0.03`.
No other style or behavior change is intended.
Use 3 symbolic colours to paint the levels in the battery bars, with a
red "error" colour used for the lowest level of battery, an orange
"warning" colour for the pre-error level, and a green "success" colour
used for levels above that.
There's no yellow intermediate colour as this is usually too anxiety
inducing and there's no real need to press users into a "warning"
behaviour when the level will still be comfortable for a long enough
time.
Closes: #725
This matches the preferences available in a lot of other OSes, whether
desktop or mobile, and can help with identifying the state of the
battery quicker for some people, as a number might be parsed quicker
than an icon/colour combination.
Closes: #481
