[Kde-hardware-devel] Missing powermanagement features in Solid

[Kevin Ottens]

Le samedi 16 juin 2007, Sebastian Kügler a écrit :
> On Saturday 16 June 2007 22:03:55 Kevin Ottens wrote:
> > Le samedi 16 juin 2007, Sebastian Kügler a écrit :
> > > Hi Solid gods, demi gods and believers,
> >
> > Hi Almighty Ass-kicker,
>
> I wonder if people will ever forget. Don't think so actually.

Well, I hope I didn't offend you. :-)
And yes, I doubt people will ever forget, but that's fine IMO... OK, let's 
move on less private stuff.

> > > While hacking on a Plasma::DataEngine that can potentially provide the
> > > necessary information for a battery applet, I found that some
> > > functionality is missing for the things I'd like to see implemented at
> > > some point.
> > >
> > > More specific, I'd like to see the following provided by Solid:
> > >
> > > - Time remaining until battery completely empty
> > > - Time remaining until battery is fully charged
> >
> > Not provided yet, actually I'm not sure where it's best to implement this
> > since this kind of information is completely unreliable, and requires
> > some learning on the battery behavior (which would be weird to do in a
> > lib imo).
>
> Well, HAL has those and I found it quite useful (gets us rid of the policy
> stuff, provides consistency for those that are running various
> powermanagement tools at the same time). GNOME's powermanager actually has
> some advanced heuristics to collect this data, I'm not sure if that's what
> we want. See for example http://hughsient.livejournal.com/28386.html

Well, those heuristics are here because the HAL information is 
(understandably) unreliable.

> Anyway, being able to get this information from HAL would be a good first
> step, one could drop in a better implementation of the remaining time some
> time in the future. The information itself is essential. Most users don't
> care about the percentage, that's battery dependant, they want to know how
> much time's left.

Well, I'm sort of reluctant to provide such unreliable information, hoping 
that it'll get magically sorted... in the meantime you have applications 
taking decision using bogus information.

Moreover, looking at the kind of application you're working on, you're not 
interested in having this information for a particular battery, but need to 
compute it for all the batteries in the system. That's why I'd advise to 
introduce this in Solid::Control::PowerManager first, since it'll be used by 
a couple of applications only, knowing the issue at hand, then when we get it 
right we'll be able to migrate the relevant parts in kdelibs, on 
Solid::Battery itself (the method on Solid::Control::PowerManager would then 
use that instead of a specific implementation).

Is it fine for you? Willing to work on it?

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."