Le vendredi 22 juin 2007, Sebastian Kügler a écrit : > On Monday 18 June 2007 20:14:24 Kevin Ottens wrote: > > Le samedi 16 juin 2007, Sebastian Kügler a écrit : > > > > > 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. > > The information is quite useful for me. While it might not be reliable, > it's still a hint, and it's much more readable for the human mind as well. > This information should IMO be provided by Solid, the 'reliability' issue > should IMO be fixed in HAL. > > How about exposing this from HAL for the short term and keep in mind that > we want to make this a bit smarter?
That's the other solution, but I'd prefer to go with Solid::PowerManager first as proposed below. This way we can manage the API better. > > > 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. > > I don't see a clear way of getting features such as "suspend when 3 minutes > of battery life" are reached. The remaining battery capacity suffers from > the same problem if I understand you correctly (It also decreases quicker > when you start tuxracer). Agreed you need such information. My point was that if it's unreliable your "suspend when 3 minutes left" means nothing, could be 30s could be ten minutes. > > 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). > > Sounds sensible to me. Ok, we'll work on it this way then. > > Is it fine for you? Willing to work on it? > > I've written in total no more than 1 KLOC C++, I doubt you would want me to > do it. :D Ooook, so or someone steps up, or you'll have to track me and chain me to my chair so that I do it during aKademy. :-) I definitely don't have the time before aKademy. 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."
pgpFKdpSlYtzM.pgp
Description: PGP signature
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
