[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Factoring out standard system information
From:       Ryan <p0z3r () earthlink ! net>
Date:       2005-12-30 19:30:14
Message-ID: 200512301430.15038.p0z3r () earthlink ! net
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]