Many users disapprove of KDE team’s decision to remove this neat little tool, me included.
https://www.reddit.com/r/Kubuntu/comments/ukcj02/what_happened_to_ksysguard_for_kubuntu_2204/
I would appreciate if KDE team reconsiders their decision and bring it back.
The replacement tools are inferior in their current state.
BOTH system-monitor and system-monitoring-center does every thing ksysguard does. FYI it’s easy enough to install yourself.
The way of adding/removing and moving columns in the new system monitor is the main problem for me, it became much complex and needs a lot of clicks via that inconsistent popup.
Inside that “Configure Columns” popup, you don’t know which column is visible until you read at right “hidden”, it would be much better if a checkbox or a highlight color was added to mark visible columns.
Also in that popup, it’s difficult to drag columns vertically because the list is too much big, it would be good if the visible columns were grouped at the beginning of the list, or simply added to a separate list.
The old way of moving columns in KSysguard was easy and fast, and adding/removing a column was done fast via two simple clicks.
I do not know which applications you are referring to, they do not pop up in Discover. If you refer to this I am not so sure I could consider that a replacement (not updated for two years).
There was a small but valuable ecosystem built around ksysguard, for instance this was really handy for me: GitHub - lestofante/ksysguard-gpu: add gpu visualization for ksysguard
All of this is gone now and people have to start over from scratch. From my point of view this is less than ideal.
ksysguard 5.22.0-2 is still available for Arch based distros, it uses the same libksysguard required by plasma-systemmonitor.
That’s not very useful for OP though, who seems to use kubuntu
And also for openSUSE Leap in the main OSS repository. I’ve removed “plasma5-systemmonitor” and re-installed “ksysguard5” –
Thanks @medin @Franken14679 for your suggestions but as eeeeeeeeee has pointed out I am on Kubuntu so these do not work for me.
I also really do not want to add unsupported/deprecated repos to my apt so it is about bringing back the ksysguard to Kubuntu.
In general, I’m afraid that “Bring back the old thing because it was much better” is not particularly useful feedback. When something gets dropped, there are always a variety of good reasons that preclude it being brought back–otherwise it wouldn’t have gotten dropped in the first place.
It’s much more useful to developers if you can articulate the specific difficulties that you’re encountering with the new thing so that they can be investigated and fixed.
I already reported a bug related to how the new system monitor degraded compared to KSysguard, but I don’t know if it’s closed or still open.
The main feature in a system monitor is the process view which gives a full view of all running processes, and the ability to show/hide different columns to diagnostic slowness and bugs. I will list some usability’s differences between the new and the old one:
1.Moving a column by dragging its header:
Ksysguard made it easy by simply left-clicking on the column header and moving it
While the new monitor made it impossible to move columns by mouse, and you need to open “Columns Config” popup where you will get stuck in that long vertical list
2. Difficult to distinguish which column is visible or not
Ksysguard made it clear: the element absent from the following list is visible
While in new monitor, when you scroll fast in that long list, it’s really difficult to distinguish which column is visible or not, and you need to read item by item to find something written different from “Hidden”
3.Adding and removing a column became complex
In KSysguad, to hide a column you simply right click on the column header, and you select “Hide…”, in the lapse of two clicks you are done.
While in the new monitor, you click on “Configure columns” button, and the popup appears, then you scroll that long list searching for your column and you click on its related combobox and select “Hidden”.
The same is for adding a new column.
…
@ngraham I appreciate you taking the time to reply. I also understand that there are always good reasons for every decision, at the end of the day you need to set priorities so general development can go on as planned.
What I criticize in general in software development nowadays is the - from my point of view - much too frequent change of user interface / user experience related features. We see that for instance on Android where with almost every new major version some basic UI features are changed, not for better or worse just changed.
My wish is that core dev team realizes Ubuntu and its derivatives nowadays are workhorses for millions of users and not everyone wants to invest a couple of hours after a new LTS release to learn new software for a rather basic tool such as a system monitor. These kind of basic tools should not be removed without very good cause and if they have to go, e.g. because they are not compatible with GTK 4 (just guessing here) why not create a replacement which is compatible with config files from the old tool for instance?
Yes, it means more work so if resources are limited fair enough. This is free software so I do appreciate all the dev efforts going into it, just sharing my thoughts here. As I do not have experience with the configuration of the system monitor and probably won’t have I cannot contribute by making specific suggestions for that new tool, other than my general thoughts. I think @medin’s comment is very helpful though.
Criticizing “in general in software development nowadays” is also not terribly useful–same with bringing up Ubuntu, Android, and GTK, which are not related to KDE or any of the technologies at play. People in KDE can’t help you with your generalized dissatisfaction with the way software not made by KDE is developed.
If you want to help, please list specific issues you’ve having like @medin did. Surely if you’re dissatisfied with System Monitor, you can describe a few of the problems that are vexing you, no? Even better, describe them in the form of bug reports–one per issue.
You may be able to download and install the .deb from the Neon Jammy repositories: Index of /user/pool/main/k/ksysguard
Or an old .deb from Focal repositories Ubuntu – Details of package ksysguard in focal
Also, if you hit Ctrl+Esc, a featureless ksysguard shall pop up as long as you have the libs installed.
The new System Monitor app is great is some respects. It seems a lot of effort went into the awesome customizable widget system. On the other hand it also has some major downsides which you can associate in some extend with all “modern” Kirigami apps.
First of all and this was already elaborated on: it loses a lot of intuitive, direct object manipulation. If you can see it you should able to interact with it! But you can’t e.g. just drag and drop table headers to rearrange them anymore. Instead there’s a dedicated “settings mode”. That throws us back decades in UI interaction.
Another aspect is performance. If your system is “acting up” you want to pull up the system monitor to see what is going on. The new system monitor is too slow to fulfill that task. Even on a decently current, idling system it takes several seconds to get actual data on the screen. It takes one or two seconds to start the app, a few seconds to populate the process viewer … aaaand whatever was causing it is gone. That gets a lot worse if the system is under load. The “old” system monitor was starting in fraction of that time providing some useful feedback.
I don’t disapprove of the current System Monitor. Technology moves forward, things have to be updated, rewritten etc. But there are perceivable downsides at least at the moment.
AFAICS, the “new” KDE Plasma System Monitor isn’t a replacement for professional remote system management tools –
As such, it seems to be a reasonable host based graphical overview of any given system’s current (live) behaviour –
Ksysgard is still available, just depends on the distro. If your distro doesn’t have it installed by default you can install it.
agree that plasma-systemmonitor is not perfectly configured by default, while the process display is too minimal.
I simply still layer ksysguard as it is a dependency or “Thermal Monitor Fix” which is the only thermal monitor widget on KDE which is completely crazy. Every window manager has such a thing.
I would be happy about help porting Thermal monitor Fix to systemmonitor or anything like that
You only need ksysguardd for Thermal Monitor Fix (not ksysguard).
There is a new Thermal Monitor for newer Plasma 5 versions and Plasma 6 that does not need ksysguardd (unfortunately it does not have as many options as the old Thermal Monitor Fix and does not work as well with panel sizes <40px or other fonts than Noto Sans - yet?):
and
Thermal Monitor - pling.com for Plasma 6.
Really sorry to bump this old thread, but it’s relevant, especially with the release of KDE Plasma 6 and apparently the complete abandonment of KsysGuard. I hope you can forgive me.
I can’t even figure out how to make plasma-systemmonitor show my proper CPU temps. I do not see my Tdie or Tctl temps from my k10temp device, it’s just showing 0’s for my core temps. They show in sensors just fine. Works in ksysguard. There’s a bug for it, it shows fixed so hopefully when I update to Plasma 6 it will just work. KDE Bug id=452763 ( can’t post a link )
How can I make System Monitor transparent like KsysGuard? That’s all I really want. Ksysguard has lived in the corner over there beautifully showing my CPU temps for a long time.
If I can’t make System Monitor not look terribly out of place or show my CPU temps, what can I use in its place?
Attached screenshots below to show what I mean.
Thanks for any help or suggestions.
I think Qt6 chart library now requires a dedicated graphic card to draw simple curves, because my system monitor on Plasma6 with Intel iGPU is now empty
https://doc-snapshots.qt.io/qt6-dev/qtquick-visualcanvas-adaptations.html
In Qt 5.0, Qt Quick always relied on OpenGL (OpenGL ES 2.0 or OpenGL 2.0) to parse the scene graph and render the results to a render target.
From Qt 5.8 onwards, Qt Quick also supports rendering in software, and with OpenVG. This is realized by having additional scene graph adaptations, either in form of plugins (openvg) or built-in to the Qt Quick library (software). The default adaptation continues to rely directly on OpenGL.
From Qt 5.14 onwards, the default adaptation gains the option of rendering via a graphics abstraction layer, the Qt Rendering Hardware Interface (RHI), provided by the Qt GUI module. When enabled, no direct OpenGL calls are made. Rather, the scene graph renders by using the APIs provided by the abstraction layer, which is then translated into OpenGL, Vulkan, Metal, or Direct 3D calls. Shader handling is also unified by writing shader code once, compiling to SPIR-V, and then translating to the language appropriate for the various graphics APIs.
Starting with Qt 6.0, the RHI-based rendering model is the default, and there is no option to fall back to directly using OpenGL.
