From kde-core-devel Fri Dec 30 19:30:14 2005 From: Ryan Date: Fri, 30 Dec 2005 19:30:14 +0000 To: kde-core-devel Subject: Re: Factoring out standard system information Message-Id: <200512301430.15038.p0z3r () earthlink ! net> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113597034719632 On Friday 30 December 2005 10:33, Adriaan de Groot wrote: > On Friday 30 December 2005 08:14, Ryan wrote: > > 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. KSysGuard seems to have a pretty complete implementation, but it's not in a library to link against. So, we could either harness ksysguard's implementation, ktimemon's version, move SK's sensor/meter stuff into some centralized location or some other solution that isn't obvious to me. The code for ksysguard is located here: kde3.5/kdebase/ksysguard/ksysguardd It seems all three try to do the same thing, so it only makes sense. Is there a way to make this more of a service than just a central resource for all apps? We could avoid some inefficiencies that way and work towards a plasma implementation.