Bug 441949 - History view: same color for all but 1 CPUs
Summary: History view: same color for all but 1 CPUs
Status: RESOLVED WORKSFORME
Alias: None
Product: plasma-systemmonitor
Classification: Applications
Component: general (other bugs)
Version First Reported In: 5.22.5
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-03 14:56 UTC by Ilia Kats
Modified: 2025-06-08 03:47 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
screenshot (308.95 KB, image/png)
2021-09-03 14:56 UTC, Ilia Kats
Details
console log of plasma-systemmonitor (11.50 KB, text/plain)
2021-09-23 12:45 UTC, Ilia Kats
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ilia Kats 2021-09-03 14:56:57 UTC
Created attachment 141271 [details]
screenshot

As the title says, the system monitor uses the same color (black) for all but one CPU, making it impossible to distinguish them (see attached screenshot). In contrast, the old KSysGuard has/had no problems choosing suitable and easily distinguishable colors (see attached screenshot). The light gray color used in the memory and network plots is also not optimal.

On an unrelated note, I also don't understand why the Y axis in the CPU plot goes up to 800%.
Comment 1 Nate Graham 2021-09-09 16:30:33 UTC
That's weird, mine doesn't do that.
Comment 2 David Redondo 2021-09-23 12:38:09 UTC
Is there something in the Konsole relating to js/qml code failing?

Can you configure those colors to other ones?
Comment 3 Ilia Kats 2021-09-23 12:45:50 UTC
Created attachment 141824 [details]
console log of plasma-systemmonitor

I'm attaching a console log of a plasma-systemmonitor run, where I just started it and then went to the history view. I don't see anything related to QML/JS failure, but `the QColor::fromHsvF: HSV parameters out of range` may be relevant.

Yes, I can edit the history view page and change the colors manually. I'd still argue that it should pick suitable colors automatically.
Comment 4 David Redondo 2021-10-01 12:40:22 UTC
Relevant code could could be:
-  https://invent.kde.org/plasma/libksysguard/-/blob/master/faces/Choices.qml#L183 which is unlikely since we are not in this path

- https://invent.kde.org/frameworks/kquickcharts/-/blob/master/src/datasource/ColorGradientSource.cpp#L93 uses this function but bounds the value using

  newHue = newHue - int(newHue);

which looks like doing the correct thing
Comment 5 Ilia Kats 2021-11-27 18:27:45 UTC
OK, apparently this is related to the color scheme in use. It works fine with the default application color scheme, but I'm using Breeze Flat Dark from https://store.kde.org/p/998662/.
Comment 6 John Kizer 2025-05-09 19:03:50 UTC
Thank you for the bug report. Because many changes have occurred in the code since this issue was reported, can we ask you to please check if this is still an issue with Plasma 6.3.5, using KDE-provided color schemes?
Comment 7 Bug Janitor Service 2025-05-24 03:47:29 UTC
๐Ÿ›๐Ÿงน โš ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Bug Janitor Service 2025-06-08 03:47:42 UTC
๐Ÿ›๐Ÿงน This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.