Just noticed the current mockups are missing disk I/O information.
That would have to be a 4th graph I guess.

Heiko Tietze wrote:Processes

Kver wrote:And the process inspector. It's a bit cramped, so I feel some tweaking is in order, but the basic idea...

PS: Using different units makes the content unnecessary hard to read. I'd either use one unit prefix (e.g. MB) or show just the percentage to the total.

The problem I have with this is: what exactly IS the total for network? For CPU/RAM it is fixed, but network has a theoretical limit which is never reached in everyday use, afaik. Which means it could end up showing something like, say, "80% network usage" when the network is actually already completely overloaded.

Also, I'm not really interested in how many % of my network is used - I want to know the exact speed. Mainly becuase for me, it would show <1% used of my gigabit link when maxing out my internet connection. So I'd rather see a KiB/s display.

Ideally, it should automatically scale the display KiB <-> MiB <-> GiB depending on traffic, because choosing a fixed unit would show something like "0.008MiB/s" or "95034.8KiB/s", which is not really all that readable.

Again my concerns are the limited number of charts. And I would expect a history per process here. However your proposal is closer to the current organization of processes.

How about this:
- no processes selected -> history for all processes
- one (or more) processes selected -> history for selected processes only.

Heiko Tietze wrote:

Soukyuu wrote:I think it might need a vertical splitter

Good idea.

...I meant a "horizontal" splitter, but you got the idea, I guess.

Soukyuu wrote:Also, I'm not really interested in how many % of my network is used - I want to know the exact speed.

If you connect the gigabit wireless to an ISDN router...
The tricky point here is that you don't want to read only high numbers but also small ones - if they are continuous. First is to know if the network is busy, second could indicate malware behavior (known from Windows). In respect to my configuration proposal (value falls below or exceed certain thresholds) we would need another statistical parameter for the notification. Log scaling perhaps? (We have to find a generic solution that covers all situation not only the particular network issue). And any chart without label (which violates every guidelines anyway) needs caption or a good indicator for the current range. BTW, that was a problem with the 4.x network plasmoid. And of course you are right, the percentage makes not much sense in the process table.

Nice reading about Linux perf tools: http://www.slideshare.net/brendangregg/ ... ance-tools

What is missing for me is the clear view of CPU usage per core (100%, 0% is not the same as 50%,50%).

For the monitor section it should be possible to have more than one diagram, as it would somehow get to overloaded. It should also be possible to have different views for the monitor as we currently have it with different tabs. Even if tabs are bad design, we need some way to switch quickly between different configurations of the monitor view (with different diagrams on it).

Also the process section has the same problem as the monitor section. I would like to have a easy way to switch between different configurations of this view (for this view it would be different kind of processes, which I already selected at the Heatmap section). The selection via the process drop down menu is not really useful as alamaki already pointed out.

I would still recommend tabs for some of your sections, to have quickly switch able configurations (like I described in my previous two sections.

stefanlahner wrote:What is missing for me is the clear view of CPU usage per core (100%, 0% is not the same as 50%,50%).

In my proposal you can have as many tiles on the overview page as you wish. The configuration offers to add tiles for every CPU, though I believe it makes not much sense for the overview. The same is true for the monitor section, it's highly configurable. More below...

stefanlahner wrote:For the monitor section it should be possible to have more than one diagram, as it would somehow get to overloaded. It should also be possible to have different views for the monitor as we currently have it with different tabs. Even if tabs are bad design, we need some way to switch quickly between different configurations of the monitor view (with different diagrams on it).

My mockup tool has limited capabilities for diagrams. The idea was to provide a view independent from processes (inaptly called heatmap) but again as much configurable as possible. If you want to see a chart for every single CPU - just add them all. You want to compare it to the core temp? Add the sensor and assign it to the secondary y-axis for proper scaling. And to allow flexible setup I'd use the same 'layout feature' as shown in the heatmap section. It replaces the tabs by making the views configurable at max.

stefanlahner wrote:Also the process section has the same problem as the monitor section. I would like to have a easy way to switch between different configurations of this view (for this view it would be different kind of processes, which I already selected at the Heatmap section). The selection via the process drop down menu is not really useful as alamaki already pointed out.

The heatmap section has a different view onto the information as it starts from the processes. Whereas 'monitor' is basically independent from the actual app (but shows the top consumers in tooltips) the 'heatmap' table could additionally show the history for the selected process only. However, the idea was to use some kind of drill-down navigation - traffic light simplicity on the overview, overall history at the monitor section, and the table of processes separated (and visualized as heatmap) from their 'advanced data' such as debug, performance or history. All these goes into another section. And since a drill-down always need an alternative way to access the current view the processes page has a dropdown. However I start this page from the heatmap and there is no need to select another process here.


Summary: My intention was to follow the requirements as collected and categorized in https://etherpad.user-prompt.com:8082/p ... KSysGuard#. Basically we need an overview for system health, a process independent view for sensors and another view that starts from a certain process, and finally we have a couple of advanced features (mostly external data) that relates to a certain process. My approach is to define a framework with maximum flexibility and predefine a couple of easy to understand presets.
Kver added another nice features but he makes the system simpler by removing configurability (as far as I understand the proposals). I don't want to utterly reject the simple solution since we can decide to focus on the most important needs. But it should be clear to everybody in case it's intended. And merging the different views might be an option too but for a clear approach I wouldn't recommend that at the present stage of development.

Hi everyone !

I'm very interested in maintaining ksysguard and making it evolve as KDE users expect it to be today.
I sent some emails to the actual maintainer, John Tapsell, and digged into the codebase of both ksysguard and libksysguard to understand how it works under the hood.

Some facts :
- ksysguard's codebase is old, (15 years old),
- there is a mix of C for ksysguardd (daemon) and C++.
- the code is complexified by the requirements of portability across multiples systems (Linux / [Open,Free,Net]BSD / Darwin / Irix / Solaris / Tru64 )
- another layer of complexity that ksysguard was originaly written as a remote system monitor, and the actual gui that everyone see today has been added on top of it.

I kept a list of the most wanted features for "Ksysguard 2.0", and most of them are visual improvements.
However, if we want to implement these new features, we have to clean the codebase first.

I have 3 questions for KDE users and the community in general :
- How many operating systems should ksysguard support ?
- In regards of all the tools that we have today for remote system monitoring, should we keep this feature in ksysguard ?
- To build a new gui, should we use QML ? I don't know anything about it's flexibility or of the potential drawbacks, but it seems to be the standard
now on Plasma desktop. Any feedbacks on developing with QML ?

Thanks !

Wenzel wrote:Hi everyone !

I'm very interested in maintaining ksysguard and making it evolve as KDE users expect it to be today.
I sent some emails to the actual maintainer, John Tapsell, and digged into the codebase of both ksysguard and libksysguard to understand how it works under the hood.

Awesome! Thanks a lot.

Wenzel wrote:I have 3 questions for KDE users and the community in general :
- How many operating systems should ksysguard support ?
- In regards of all the tools that we have today for remote system monitoring, should we keep this feature in ksysguard ?
- To build a new gui, should we use QML ? I don't know anything about it's flexibility or of the potential drawbacks, but it seems to be the standard
now on Plasma desktop. Any feedbacks on developing with QML ?

Giving some feedback of what I had heard over the years: the remote system is one of the core features of ksysguard which is actually used on large installations. Those users you won't reach through forums here. Related to that is the list of obscure operating systems. If you drop one you run in the issue of possibly breaking someone's workflow. My suggestion on that would be to not touch the daemon and try to keep compatibility as long as it compiles. For new features: go Linux only. Nothing wrong with that, we just need to accept the fact that Linux left all other OSes behind in this area

The third question is the most important. I think that QML could provide a good improvement for the UI. The true challenge is to integrate the old code base with QML (been there, done that). My hope is that the remote feature actually helps you in that regard as it should have a separation from data, logic and GUI. Lot's of old code normally has the logic implemented in the widgets, which turns a port to QML into a nightmare.

I suggest that you contact the QML experts from Plasma. We have a weekly Google+ hangout Mondays at 12 CET. Feel free to join, the link is posted in #plasma on freenode. Also we might have a developer sprint in March.

Bear in mind the concerns reg. "spectacle" (ksnapshot replacement showing up too slow; see mailing list, was ported back to QWidget) or our troubles with QtQuick views.
If that's not gonna be fixed, sth. like ksysguard (which is used as a "process/task manager", ie. invoked by ctrl+alt+del on the fly - if things go wrong anyway) might suffer badly from the QtQuick initiation overhead.

Hi !

luebking wrote:Bear in mind the concerns reg. "spectacle" (ksnapshot replacement showing up too slow; see mailing list, was ported back to QWidget) or our troubles with QtQuick views.
If that's not gonna be fixed, sth. like ksysguard (which is used as a "process/task manager", ie. invoked by ctrl+alt+del on the fly - if things go wrong anyway) might suffer badly from the QtQuick initiation overhead.

Thank you for mentioning this !
I have never used QML in a real application and wasn't aware of this potential performance issue at application startup.

=> Would it be possible to use the QtQuick Compiler when releasing the app to solve this problem ?

I'm working on a little library (libsysinfo) to abstract all the /proc parsing from ksysguard display or daemon code logic.
I would like to create a prototype of the new ksysguard ui in QML, in order to determine if QML might be a good choice or not.

I really don't know how to create an app in QML, apart from painted a rectangle in blue and setting it's width and height
Does someone could help me to build this prototype ?

The goal would be to have these features :
- process listing
- detailed process view
- network connections (tcp, udp)
- unix sockets
- ram usage
- graphs

Thank you !

[Edit]
Ok, I worked a little on the QML ui this night and I have a working process listing (see ./_build/tests/gui_qml/test_gui_qml)

For the new ksysguard developers,
when you start it from ctrl+esc it appears in "keep above others" mode,
that means other windows can't cover it.
This is great, except when you try to kill a root process.
In that case a window asking for privileges will appear, bu obviously it is covered by ksysguard and you cannot see it.
I lost 10 minutes trying to figure out why ksysguard won't ask me for my password.
So my suggestion is to make the password window in "keep above others" mode, like ksysguard, when launched from ctrl+esc.

=> bugs.kde.org - posting it /here/ is like telling it to the next wall.
The problem will hardly be the keepabove bit, but that the PW dialog isn't marked transient for the sysguard window (as it should be)

Any update on the new ksysguard features.

Really tired of not being able to monitor per process network usage.

Hi xavier8338

As you requested an update, I will describe my progress on this project.

As i said in a previous, I reviewed ksysguard code for quite a long time, and since it was too difficult to
do a single modification, i decided to build a prototype of the next ksysguard, both in term of UI design and software architecture.

I started by developing a library to access system information, then I displayed the data
in a process monitor named kmonitor.

After that, I reviewed user's expectations, and I thought that it would be easier to rebuild the tools available on windows in the sysinternals suite.
That's why I started to rebuild the vmmap tool to give it a try.
A demo of vmmap is available here

the next step will be to develop a clone of process explorer, and have the same features as the original, so that everyone could check their running processes against virustotal for example.

being able to filter the network usage would be nice, but for the moment i'm focusing on having something that just works

Anyone willing to help can contact me and join the github project !

Thanks !

Hi Wenzel,
That is awesome . really glad to see you made so much progress. will try to help out.
Thanks!

Hi everyone !

I will give you another update of the project :

I was able to use the Process Connector feature of the linux kernel to send notification of fork/exec/exit events to the process monitor using DBus.
This means that i can update the view and insert / remove processes nearly at the same time as they are created !
And I also implemented cpu usage.

I uploaded a demo that you can find here.

The next steps will be to implement io usage and network usage.

Thanks for your support !