This helper tool launches the Power Settings panel in a fake
environment, making it easy to test the UI in different scenarios. The
tool allows:
- cycling through power-profiles-daemon degraded performance reasons
- adding and removing a laptop battery, keyboard, mouse or UPS
UPS support needs umockdev 0.17.4 to work correctly
Ignored in Meson < 0.60.0, deprecated since 0.60.1 and fatal since 0.61.0.
panels/applications/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/background/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/camera/meson.build:10:5: ERROR: Function does not take positional arguments.
[...]
They were originally included was to educate users about what the icons
mean, for when they appeared in the top bar. However, since we no
longer plan on showing the status icon in the top bar, it's not so
important that people learn the meaning of the icons.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1421
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 }
While the code was using the pattern to cancel the operation, it was
still resolving the user_data pointer even in the case the operation has
been cancelled.
Fix this by simply moving the initialization.
Fixes: #1260
