Factoring out standard system information

Adriaan de Groot groot at kde.org
Fri Dec 30 15:33:24 GMT 2005

On Friday 30 December 2005 08:14, Ryan wrote:
> 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.

Yeah, but that's the way it's got to be done. My suggestion is to centralize 
this in _one_ place and do something like the folllowing:

create classes SampleCPU, SampleSwap, SampleMem (and perhaps others) that 
provide a single interface (SampleCPU::idle(). SampleMem::free()) and an 
update mechanism (Sample::update()) to re-read the information they're for. 

> 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.

It might be a good idea to move the stuff from SK in trunk into libs at some 
point so that other system monitor thingies can use them.

These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051230/501269ac/attachment.sig>

More information about the kde-core-devel mailing list