battery plasmoid and remaining time..
sebas at kde.org
Thu May 14 10:22:55 CEST 2009
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
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
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.
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090514/62f6d134/attachment.sig
More information about the Plasma-devel