Factoring out standard system information

Ryan p0z3r at earthlink.net
Fri Dec 30 07:14:40 GMT 2005

On Thursday 29 December 2005 21:00, Adriaan de Groot wrote:
> There's a couple of non-portable system things that are really popular to
> know for KDE applications. These are CPU information (load; percentage time
> idle, interrupt, user, etc.), swap and RAM information (free and used).
> Reading these data is a pain in the ass, and it's implemented who knows how
> many times across the KDE codebase -- superkaramba, ksysguard and the just
> discovered (and hopelessly buggy) ktimemon come to mind. I think SK has the
> most accurate code - at least it gives me numbers that match what top(1)
> and swapinfo(8) tell me. KTimeMon has support for OSF but not for FreeBSD,
> which is .. uncomfortable and/or weird.

SK's implementation is done by reading /proc files in regards to running on 
linux.  Free/NetBSD is a bit different, but to the same degree.  However this 
is done for each theme that asks for that info which is non-efficient 
unfortunately.  This method, as you mention, is very non-portable as well.

> So would it make sense to factor this stuff out and stick it in kdelibs
> somewhere? ksysinfo or some such -- one central place to query system
> resource usage, so there's only one place reading /proc/icky/memusage or
> calling sysctlbyname("hw.memusage") or calling table() or using kvm(4).
> How does that square with SK's merger into plasma? The system resource
> reading is some of the most popular stuff in SK.

There have been discussions on how to access this information in some form of 
a singleton and is getting there in /trunk's SK codebase.  However I remember 
there being discussions about it becoming more central to KDE instead of a 
per app implementation in the future.  One that comes to mind is a net load 
project, but I don't know who's doing the work on it.

More information about the kde-core-devel mailing list