battery plasmoid and remaining time..

[Sebastian Kügler]

Hi,

On Thursday 14 May 2009 03:07:43 Aaron J. Seigo wrote:
> so .. http://websvn.kde.org/?view=rev&revision=915184
>
> when did we start adding features that have no chance in hell of actually
> working accurately?
>
> i love how my battery had 0:00 time just a second ago, even though it's
> fully charged, and now it has 0:18 left. these are bullshit numbers, not
> only because apparently the hardware drivers don't actually work but
> because even when they do it varies according to workload that can and does
> shift wildly from minute to minute on most machines. yes, i'm looking at
> you flash enabled websites.
>
> and here we are accommodating the display of such misleading information by
> adding more paths to our code and more widgets in our options dialogs.
>
> can someone provide a justification, other than idiot pacification, for
> r#915184

Yes. The percentage is even less relevant, a bad battery can show 100% and 
still go down within two minutes.

The time remaining gives at least an approximation of what the user can 
expect, and does so in a *meaningful* way (by providing an absolute number).

I understand that it has two problems:

(a) It's unreliable on certain machines (yours, as an example)
(b) It depends on the workload

As to (a), those machines or drivers should be fixed instead of removing a 
very popular and often useful features from the UI. It works well on many 
machines, including mine (a Thinkpad T60) and the time reported is actually 
pretty accurate and reliable. I'm not willing to sacrifice a useful feature 
because some BIOS or drivers don't get it right.

(b) is a fair point partly. Though I'm not sure it's really relevant. Here's 
what happens in my mental model: The user checks the percentage and tries to 
interpolate from that if he can finish reading this text, writing this long 
email, or watching this movie. For all those cases, the percentage isn't 
interesting, she needs to know the time (it'll take 40 minutes to finish the 
task, the movie lasts another 1.5 hours). Note that in those cases, the 
activity will usually remain mostly the same, hence the consumption of energy, 
and hence the time reported.
In any case, the user does need the time, not the percentage. I often found 
myself trying to guess the remaining time from the percentage, and that's a 
very complex thing to do (you have to measure over a period of time).

You're also talking about data loss, which I think is an invalid point. The 
automatic suspending mechanism is still percentage-based, so the time display 
doesn't have any influence there, the machine will warn and go to sleep when 
the battery runs out. Monitoring that is not something the user should need to 
do, and that's reflected in the current implementation.

I'd happily welcome an approach that makes the time reported better though. 
The GNOMEs have code to record and interpolate power consumption, I think 
similar to the code that computes the system load), this might be a solution 
to make the number reported more accurate. It should probably even go into 
HAL.

I'm not sure how HAL does it right now, if it only uses the current discharge 
rate, then there's a lot of room for improvement, easy to pick fruit.

This is largely why I accepted this patch.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090514/62f6d134/attachment.sig