Created attachment 135244 [details] Current results SUMMARY Contrary to 5.19, automatic scales are now cumulative. Even when it makes nonsens (example memory charts). STEPS TO REPRODUCE 1. Create memory monitor plasmoid 2. Change to line diagram 3. Add sensors 4. Select cumulative lines option in diagram details OBSERVED RESULT I have 8 Gio of RAM. Left (with cumulative lines): scale is 3×8. Right: 8 (without cumulative lines, but less readable). EXPECTED RESULT I want cumulative line: it is better to see the distribution. Otherwise the line will be overlaid each other. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION None
Probably this: https://invent.kde.org/plasma/libksysguard/-/merge_requests/48
Created attachment 135333 [details] A dirty patch… My dirty patch… to detect the max scale. But it will probably fail in some cases (which I do not have :/). Better idea would be to have a detection of sensor that you have to cumulate the scale or other not. diff --git a/faces/facepackages/linechart/contents/ui/LineChart.qml b/faces/facepackages/linechart/contents/ui/LineChart.qml index 34f2888..252eafd 100644 --- a/faces/facepackages/linechart/contents/ui/LineChart.qml +++ b/faces/facepackages/linechart/contents/ui/LineChart.qml @@ -61,7 +61,7 @@ Charts.LineChart { function calcStackedMaximum() { let max = 0 for (let i = 0; i < sensorsModel.sensors.length; ++i) { - max += sensorsModel.data(sensorsModel.index(0, i), Sensors.SensorDataModel.Maximum) + if (max<sensorsModel.data(sensorsModel.index(0, i), Sensors.SensorDataModel.Maximum)) max = sensorsModel.data(sensorsModel.index(0, i), Sensors.SensorDataModel.Maximum) } return max }
So what you are seeing is technically correct but that each of the memory sensors has a theoretic maximum of the full amount of RAM in your system. In reality however the sum of all sensors would never exceed the amount RAM in your system. For now you probably want to set the limit manually.
Created attachment 135356 [details] Manual scale Hi David, It is not possible to set manually the maximum because the manual maximum is 99999 bytes. I can not go further. Bad field limit? or unit (it should probably be in Mio)? Yes, it is technically correct. In fact, cumulate the maximum is useful for load averages, disk usages, bandwith, CPU usage… But not for physical limits like RAM, % of disk usages…
Not sure there is a maximum set for load averages, bandwith and CPU usage. I wrote a nonsense here.
You are right in the CPU case where each core can go to 100% the maximum needs to be 400% if you have 4 cores. But for memory since each value is part of the same total we do not want to add it. 99999 as the maximum is bad since the memory is measured in bytes and manually inputting that will also not be fun. Until we have a proper solution for this case or we fix the manual edit, you can edit ~/.config/plasma-org.kde.plasma.desktop-appletsrc, search for the title or sensors of you widgets to identify it, for example the title in the group [Containments][71][Applets][93][Configuration][Appearance] then you can edit the range in the config file in the group like so [Containments][71][Applets][93][Configuration][org.kde.ksysguard.linechart][General] rangeTo=1000000 I know this is a bit of a cumbersome workaround but should work until we have a better thing.
As you said, It is not fun. But it works. Thanks
The problem with the proposed behaviour is that it's impossible to determine programmatically when certain sensors should stack and when they should not. For the example given (application/cache/buffer usage) it makes sense to not stack them, while for another set of sensors, such as Used Physical Memory with Used Swap Memory you want them stacked. If you were to combine Used Physical Memory with application/cache/buffer, you'd want them stacked simply because anything else makes no sense. A few versions ago we improved the behaviour of setting the ranges for charts, so the workaround for editing the config file should no longer be needed and the range can simply be set to something like "8 GiB". I think this should cover most of these cases.
(In reply to Arjen Hiemstra from comment #8) > A few versions ago we improved the behaviour of setting the ranges for > charts, so the workaround for editing the config file should no longer be > needed and the range can simply be set to something like "8 GiB". I think > this should cover most of these cases. It is in my case. Thanks for the reply.