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