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