Bug 446414

Created attachment 144168 [details]
screeen recording

Please watch the attached screen recording.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/libksysguard/-/merge_requests/210

A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksystemstats/-/merge_requests/30

Git commit f2a09fc6063f279a913916b9fdad9e8227890c2e by Arjen Hiemstra.
Committed on 01/02/2022 at 15:45.
Pushed by ahiemstra into branch 'master'.

Check initial value is valid before resetting in SensorProperty::unsubscribe

This way, we only reset the value if we originally got a valid value.
This allows us to indicate what behaviour we want when constructing the
SensorProperty. Some documentation has been added about that to the
relevant constructor.

M  +3    -1    systemstats/SensorProperty.cpp
M  +13   -0    systemstats/SensorProperty.h

https://invent.kde.org/plasma/libksysguard/commit/f2a09fc6063f279a913916b9fdad9e8227890c2e

Git commit 953021995c73278f744a0d020341301fdec6fc1f by Arjen Hiemstra.
Committed on 01/02/2022 at 16:11.
Pushed by ahiemstra into branch 'Plasma/5.24'.

Check initial value is valid before resetting in SensorProperty::unsubscribe

This way, we only reset the value if we originally got a valid value.
This allows us to indicate what behaviour we want when constructing the
SensorProperty. Some documentation has been added about that to the
relevant constructor.


(cherry picked from commit f2a09fc6063f279a913916b9fdad9e8227890c2e)

M  +3    -1    systemstats/SensorProperty.cpp
M  +13   -0    systemstats/SensorProperty.h

https://invent.kde.org/plasma/libksysguard/commit/953021995c73278f744a0d020341301fdec6fc1f

Git commit 40be1b73c06c52073c525cf77934aa8877097e32 by Arjen Hiemstra.
Committed on 01/02/2022 at 15:25.
Pushed by ahiemstra into branch 'master'.

Set proper initial values for many SensorProperties

SensorProperty in libksysguard was changed to reset the value of a
sensor on unsubscribe. However, this caused a number of "static" sensors
to break and only provide their value once. To fix this, SensorProperty
will now only reset the value if a valid initial value was provided.

This changes many SensorProperties to have valid initial values. This
has been applied primarily to sensors that are very volatile and which
provide a different value almost every update, like the various rate
sensors as well as the usage percentage sensors. For these sensors, it
is unlikely thata a historical value makes any sense.

Other sensors, like memory usage, are less volatile and will generally
not vary wildly, so providing a historical value for those seems better
than an empty value.

M  +6    -6    plugins/cpu/cpu.cpp
M  +2    -2    plugins/cpu/freebsdcpuplugin.cpp
M  +3    -3    plugins/cpu/loadaverages.cpp
M  +4    -4    plugins/disks/disks.cpp
M  +1    -1    plugins/gpu/AllGpus.cpp
M  +4    -4    plugins/gpu/GpuDevice.cpp
M  +3    -3    plugins/gpu/LinuxAmdGpu.cpp
M  +4    -4    plugins/network/AllDevicesObject.cpp
M  +5    -5    plugins/network/NetworkDevice.cpp
M  +13   -13   plugins/osinfo/osinfo.cpp
M  +2    -1    plugins/power/power.cpp

https://invent.kde.org/plasma/ksystemstats/commit/40be1b73c06c52073c525cf77934aa8877097e32

This bug persists with system sensors.

Operating System: Arch Linux
KDE Plasma Version: 5.24.1
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Graphics Platform: Wayland

Git commit 118c4bdf3b46bf20e93d02bdc4470eac1fa80baa by Arjen Hiemstra.
Committed on 11/05/2022 at 10:49.
Pushed by ahiemstra into branch 'Plasma/5.24'.

Set proper initial values for many SensorProperties

SensorProperty in libksysguard was changed to reset the value of a
sensor on unsubscribe. However, this caused a number of "static" sensors
to break and only provide their value once. To fix this, SensorProperty
will now only reset the value if a valid initial value was provided.

This changes many SensorProperties to have valid initial values. This
has been applied primarily to sensors that are very volatile and which
provide a different value almost every update, like the various rate
sensors as well as the usage percentage sensors. For these sensors, it
is unlikely thata a historical value makes any sense.

Other sensors, like memory usage, are less volatile and will generally
not vary wildly, so providing a historical value for those seems better
than an empty value.


(cherry picked from commit 40be1b73c06c52073c525cf77934aa8877097e32)

M  +6    -6    plugins/cpu/cpu.cpp
M  +2    -2    plugins/cpu/freebsdcpuplugin.cpp
M  +3    -3    plugins/cpu/loadaverages.cpp
M  +4    -4    plugins/disks/disks.cpp
M  +1    -1    plugins/gpu/AllGpus.cpp
M  +4    -4    plugins/gpu/GpuDevice.cpp
M  +3    -3    plugins/gpu/LinuxAmdGpu.cpp
M  +4    -4    plugins/network/AllDevicesObject.cpp
M  +5    -5    plugins/network/NetworkDevice.cpp
M  +13   -13   plugins/osinfo/osinfo.cpp
M  +2    -1    plugins/power/power.cpp

https://invent.kde.org/plasma/ksystemstats/commit/118c4bdf3b46bf20e93d02bdc4470eac1fa80baa

Turns out this was correctly fixed on master and I simply forgot to cherry-pick the relevant commit in KSystemStats to 5.24.