On Fri, May 15, 2009 at 6:14 AM, Zack Rusin <z...@kde.org> wrote: > On Thursday 14 May 2009 23:22:46 Chani wrote: >> > > It's not made up, as far as I can see it's remaining capacity / current >> > > discharge rate. So it does tell you when your battery runs out if you >> > > keep doing what you're doing right now. >> > > >> > > Maybe a good point is to think about how we can make this more clear to >> > > the user. >> > >> > I'd suggest prefixing that number with an icon of a dude going "3 >> > hours... no, 2 hours! no! 1:30! no 6 hours! oh, for gods sake, i give up" >> > and then an animation of him throwin his hands up in the air. that'd >> > pretty much express exactly what it's doin. >> >> "four hours and ten minutes! four hours and eight minutes! four hours and >> fifteen minutes! four hours and five minutes!" >> who cares, at least I know I've got around four hours left. >> I don't know what sort of hardware you've got, but my battery doesn't vary >> that wildly. I managed to make it go down from 4:20ish to 3:50 by starting >> a compile, but that's as much as it's jumping. > > nope, that's crap. if *you* don't see a huge difference between idle processor > and a movie playing/compile/gamin then it's your hardware that's shite. or do > you actually think that all those patching of all the apps to not run extra > timers was to save a minute or two? > >> > of course that's also what "2 hours left" can mean. >> >> if that's true then your hardware *sucks* > > nope, as noted above it's your hardware that sucks if that's not the case. an > idle 13" laptop with no usb pollin devices should be takin about 10Watts. > lowerin the screen brightness to maximum will win you a few watts as well. > playin a full screen movie, compilin, playin a game, etc it will likely jump > to 20Watts+. if you don't see that then your acpi setup is busted. so we're > talkin about hours of difference (especially for people with larger > batteries). > > as to the rest, it's about feelings, which honestly is a shite discussion to > have in a context of a development list. my point is "it's wrong to have a > computer guess/lie", yours is "but it's nice!", which is a discussion no one > can win. as i said in my last email "if we only had like, i don't know, a > 'usability team' to look at those issues!".
I've just read the whole discussion, and this is my point of view on all this: * Most users will find useful an indication of how much time is left in a device which has only some hours of battery such as a laptop/netbook. I could be optional, but active by default. * It's difficult to calculate accurately and we cannot predict the future, and some devices are broken. But if we relay on recent battery usage and percentage of battery left, which I've experienced both are fairly accurate measures, we can guess the future usage and get a good enough predictions for most of the time. You've been using 10W+-2W for last 10 mins, and in 10mins the battery has decreased 2%. We can predict that if the battery usage continues that way and the battery % decreases linearly, you've got X mins left. when we have less than X% of battery, we can be warier and tend to worst-case scenarios just to play it safe. An use case scenario: some background process - cron, nepomuk, amarok indexing, whatever - rises the battery usage to 17W, well then what we do? when usage changes enough we can tell the user somehow. For example we have a visual indicator in the battery plasmoid for the % of battery left, and we have a yellow ray at one side which moves from there when we don't have the plug connected. we could reuse that ray to somehow hint if the battery is being consumed faster than recently predicted (a more obvious ray, perhaps a redder ray if consumption rate rose?), readjust the prediction and flash "1h left" on the top of the applet. This flash feature needs to be enough for the user to notice it but be not so prominent as to be able to ignore it easily too (just a good compromise), and should only be used when battery consumption rate changes enough to be noticeable time-wise. Some people have suggested using normal-case and best-case scenarios, something which is becoming much more useful in devices in which battery draining can change from 10-W to 20+W depending on level of CPU/USB/monitor/etc usage. We could make that an option, and let the packagers make it default or not depending on the distro (if someone is using plasma in n810 it's more likely they want that option active by default) or directly the hardware. Anyway with the "battery consumption rate changed flash" described above, that might be less of a problem. Just my 2ct. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
