No "remaining time" option in battery monitor?

Ben Cooksley bcooksley at kde.org
Fri Jun 15 09:20:49 UTC 2012


On Fri, Jun 15, 2012 at 12:08 PM, Shaun Reich <sreich at kde.org> wrote:
> To me it looks less like a "discussion" and more like a "aaron got pissed
> because it didn't work for him, who himself is one person therefore nobody
> should have it".

Hi Shaun,

Just a quick reminder that KDE has a document regarding these sorts of things:
The KDE Community Code of Conduct (http://www.kde.org/code-of-conduct/)

I would recommend a quick read.

(If you haven't read this document before, I recommend reading the
preamble and overview at the very least)

>
> If not all hardware supports it, tough shit we've been shipping compositing
> on so much hardware that couldn't support it even in a remote sense yet did
> it anyways. And these days compositing works pretty darn well on even less
> mature Foss drivers. Do you see parallels here? I don't know, power top
> manages to get the info just fine.
>
> Of course it is by nature inaccurate, but you know what? So is guessing how
> much % is left. So you're simply wrong, anything associated with a battery
> can be easily argued as inaccurate, because it is. You know that battery %
> cannot be measured just from VA alone with Li-ion, many other factors need
> to be taken into consideration, especially temperature. Otherwise the values
> you're getting could be at least 20% off. So maybe we should stop displaying
> the percentage of the battery, and just tell the user that their computer is
> on. And when it is off, we won't tell them anything.
>
>
> Time remaining applies to a lot of things, and since it's all hardware, it's
> all inaccurate but does give you a rough idea, look at backup power
> supplies; also, even cars have it these days(in the form of mpg and miles
> remaining as well as minutes). The user doesn't expect it to be 100%
> accurate, because it can't be and it never was, they already know that.
>
>
> Given this logic, perhaps we should also abandon file transfer ETA and just
> say "it's done when it's done", since inter/intranet bandwidth and internal
> I/O operations vary so greatly with access times and scheduling, there's no
> way to possibly give you an accurate time, and the users won't be able to
> trust it ever because it switches from "1 week" to "4 hours". And yet we
> do...? Because it's common functionality and is expected..
>
>
> That said, every other OS under the sun manages to do ETA just fine, so
> what's the problem?
>

Regards,
Ben Cooksley

>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>


More information about the Plasma-devel mailing list