https://bugs.kde.org/show_bug.cgi?id=434877
--- Comment #43 from Mark <mark...@gmail.com> --- I see no comment i'd consider spam. But i do see some being marked as such. It's sad imho. Much of the comments here are criticism but in a, in my opinion, fair manner. I think it's oke to criticize a product where it's intended purpose isn't working as intended. (In reply to Ville Aakko from comment #42) > I suspect from the comments (someone involved in the project correct me if > I'm wrong) that System Monitor will not be fixed. It's codebase seems too > hairy, no-one seems to actually know what the real issue is properly. Note: > as I've said before, the **bulk** of the problem is not gathering process > information, although I'm fairly certain that problem also has problems. The > CPU usage is abnormally high when just drawing sensors information from > lm-sensors. > > Generally, bug listings should be reserved for comments only relevant > working towards fixing the issue. However if this seems unlikely, comments > about alternatives should be allowed (IMHO); so the comments marked as spam > should not be marked as such. I don't see much ranting here. > > I've already moved on to alternatives. Projects such as btop (for terminal) > coolercontrol work well for showing sensor information. > > I'd be interested in any efforts/projects to start from scratch building a > working monitoring application for KDE Plasma. I don't know if I'd be able > to contribute, but I've used a lot of different monitoring applications > (geared for servers and desktops alike) and know of a few caveats, in > addition to resource usage. For example, there's a long-standing (from > ksysguard) issue of assuming static structures in /sys/class/hwmon (see bug > #466277), which get's exacerbated every year since more and more devices get > lm-sensors support (my computer has 7-9 hwmon devices, depending on which > USB devices I have plugged in). For a to-be application, a list of minimum > set of requirements should be made before starting any development work > (judging from the state of Plasma System Monitor, this was not the case when > it was developed). I'd be interested in building such a project too. The tricky thing isn't even building the library. Just fork the part from btop and you already nearly have it. The tricky part is not screwing up the performance in the GUI layers to represent that data. The current UI is super configurable with even drag/drop. Someone must have spend many weeks on that i'd assume. I'm not saying that on it's own is bad. A new library behind the scenes isn't going to make things magically faster. I'd be confident in saying that 99% of the current time is spend outside the metric collection (and thus in the UI). To me, all the stuff in the backend and UI is just waaaaay to hairy! I'm not even gonna try and touch that as it's just gonna take days (weeks probably) to refactor it. Thank you for letting us know that there is a KSysGuard KF6 port even though dirty (https://github.com/zvova7890/ksysguard6/tree/kf6)! It seems clear to me what should happen: - Remove plasma-systemmonitor and work on it behind the scenes (re-introduce it later on when it's not a resource hog anymore) - Temporary revert back to KSysGuard There's probably a bit of pride involved here too for whoever wrote plasma-systemmonitor and rightfully so! It's a beautiful product (in screenshots). But as it stands, it's just not functionally usable so the wise thing to do is go back to what worked. It's not like there hasn't been time, plasma-systemmonitor has been there for some years already. It's just a component that doesn't have many devs (https://invent.kde.org/plasma/plasma-systemmonitor look at the commits, it's essentially unmaintained) so fixing it isn't gonna happen in the near future it seems. -- You are receiving this mail because: You are watching all bug changes.
