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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
