Is there a mouse-over hint displaying the full text at least?

No, there is nothing like that. The percents remain unreadable.

The way I expected it to work is to have a min and a max width (where the maximum is about 380px). The menu would expand up to the max width to accommodate longer strings. Text would only be ellipsized after it had reached the upper limit.

Created attachment 255581 [details] [review]
aggregate-menu: Increase width

Add 20px more width to make longer strings (translations) fit better.

--

<aday> drago01_, i guess you could try adding the bare minimum to make it work in that case - 10 or 20 px

That patch does that i.e add 20px which is as far as we can go. Lets hope that'S enough ... we need a better fix for 3.12

Comment on attachment 255581 [details] [review]
aggregate-menu: Increase width

Attachment 255581 [details] pushed as a06a78a - aggregate-menu: Increase width

Pushed with rt approval ... leaving the bug open for a better 3.12 fix.

(In reply to comment #5)
> (From update of attachment 255581 [details] [review])
> Attachment 255581 [details] pushed as a06a78a - aggregate-menu: Increase width
> 
> Pushed with rt approval ... leaving the bug open for a better 3.12 fix.

The better fix would be to have menus automatically adjust their size. Whether it's worth going to all that effort for St is an open question though.

(In reply to comment #6)
> (In reply to comment #5)
> > (From update of attachment 255581 [details] [review] [details])
> > Attachment 255581 [details] [details] pushed as a06a78a - aggregate-menu: Increase width
> > 
> > Pushed with rt approval ... leaving the bug open for a better 3.12 fix.
> 
> The better fix would be to have menus automatically adjust their size. Whether
> it's worth going to all that effort for St is an open question though.

They already do that if we don't specify a width at all. The problem is that the (may) submenus contain content that is either wider or narrower then the primary menu. Which makes it look "jumpy". 

You can try it out by removing the ".aggregate-menu { ... }" section from the CSS.

Created attachment 256541 [details]
Screenshot of the 3.10.0 situation

Thank you for mitigating the issue for 3.10.0. It solved the "Remaining" case, but unfortunately not the "Until Full" one. I agree that adding more pixels is not a solution, the screenshot just shows that a better fix is needed.

Is there anything that can be done to fix this? It's still a problem in 3.16: bug #753404.

I would argue that we should hide this information because:
- it's unreliable when the workloads vary wildly, it just tells you how much time you'd get out of the battery "at the current rate".
- it's unreliable on a number of devices, including BayTrail tablets that report wild values for raw consumption values. As Windows and Android don't rely on it, nobody cares about fixing the firmware bugs.

See also https://bugs.freedesktop.org/show_bug.cgi?id=91660 about doing that for UPower. If we were to do that in gnome-shell, we'd also need to remove that information in gnome-control-center's Power panel.

Richard, what do you think?

As a user, even though I know it's a rough estimate, it's still good to know if I have 20 minutes remaining or 6 hours remaining. I know that power consumption is tricky, but a ballpark estimate is good and I want to keep it.

(In reply to Jasper St. Pierre from comment #11)
> As a user, even though I know it's a rough estimate, it's still good to know
> if I have 20 minutes remaining or 6 hours remaining. I know that power
> consumption is tricky, but a ballpark estimate is good and I want to keep it.

Yeah while I don't care much about the time its a good way to tell me "plug in your laptap asap".

(In reply to drago01 from comment #12)
> (In reply to Jasper St. Pierre from comment #11)
> > As a user, even though I know it's a rough estimate, it's still good to know
> > if I have 20 minutes remaining or 6 hours remaining. I know that power
> > consumption is tricky, but a ballpark estimate is good and I want to keep it.
> 
> Yeah while I don't care much about the time its a good way to tell me "plug
> in your laptap asap".

Except that it won't be reliable data. I'm pretty sure you can figure out, just like people do regularly on phones, that you should really plug in your laptop at 5% battery.

We'd need a way to show the exact percentage in the status icon though, as is possible on the aforementioned phone OSes.

(In reply to Bastien Nocera from comment #13)
> (In reply to drago01 from comment #12)
> > (In reply to Jasper St. Pierre from comment #11)
> > > As a user, even though I know it's a rough estimate, it's still good to know
> > > if I have 20 minutes remaining or 6 hours remaining. I know that power
> > > consumption is tricky, but a ballpark estimate is good and I want to keep it.
> > 
> > Yeah while I don't care much about the time its a good way to tell me "plug
> > in your laptap asap".
> 
> Except that it won't be reliable data. I'm pretty sure you can figure out,
> just like people do regularly on phones, that you should really plug in your
> laptop at 5% battery.
> 
> We'd need a way to show the exact percentage in the status icon though, as
> is possible on the aforementioned phone OSes.

Well sure but the difference is that the notification grabs my attention while the battery icon is not something that I keep looking at while working / reading etc.

If we'd show the "please plug in your laptop" notification at 5% battery it be good enough for me (as I said before the time does not really matter to me all it tells me "battery is almost empty").

Created attachment 310765 [details]
3.18 screenshot

This isn't much better in 3.18. Many strings get cut. The one on the screenshot is not even the longest one, and many languages might have strings twice as long as the English ones. I believe some sort of dynamic width is necessary.

*** Bug 734059 has been marked as a duplicate of this bug. ***

*** Bug 753404 has been marked as a duplicate of this bug. ***

(In reply to Piotr Drąg from comment #15)
> I believe some sort of dynamic width is necessary.

The tricky bit is that we don't want the menu width to grow indefinitely by strings that are outside our control (device/network names).

*** Bug 755475 has been marked as a duplicate of this bug. ***

*** Bug 755544 has been marked as a duplicate of this bug. ***

(In reply to Florian Müllner from comment #18)
> (In reply to Piotr Drąg from comment #15)
> > I believe some sort of dynamic width is necessary.
> 
> The tricky bit is that we don't want the menu width to grow indefinitely by
> strings that are outside our control (device/network names).

While this is true the current way looks even more unpolished IMHO.

Created attachment 312083 [details] [review]
aggregate-menu: Allow adjusting of the menu width

Currently the menu is too narrow for some translated texts causing them to be
cut off.
We do not want to allow an arbitary wide menu so as a compromise allow growing
up to a maximum size that is considered acceptable.

(In reply to drago01 from comment #22)
> Created attachment 312083 [details] [review] [review]
> aggregate-menu: Allow adjusting of the menu width
> 
> Currently the menu is too narrow for some translated texts causing them to be
> cut off.
> We do not want to allow an arbitary wide menu so as a compromise allow
> growing
> up to a maximum size that is considered acceptable.

So this tries to use the "new" (3.18) width while allowing to grow up to the "old" (3.16) width. 

That's the best I can think of for 3.18.1 ... we might want something fancier for 3.20 but leaving it as is is not really an option.

(In reply to drago01 from comment #23)
> So this tries to use the "new" (3.18) width while allowing to grow up to the
> "old" (3.16) width.

Of course that means that this only fixes the issue for locales where this became a problem in 3.18, not where this already was an issue before.

If this is indeed the best we can come up with for 3.18.1, then it's better than nothing of course - however I wouldn't outright dismiss the possibility yet to properly address this in the remaining fortnight.

Created attachment 312101 [details] [review]
power: Stop making time estimates

So here's an alternative based on comment #10 - simply show the percentage instead of a time estimate.

(I don't think removing the time estimate necessarily means it has to be removed from the Power panel as well, though the unreliability argument obvious applies there as well)

Note that this patch breaks the string freeze, so it would be good to get design feedback soonish in case we have to make a freeze break request.

Review of attachment 312101 [details] [review]:

This looks good. 
But it only fixes one of the issues (power). 
Another problematic thing are the network items (due to the inclusion of network names like "Ethernet (ethx)").

And Bluetooth, "Not in use" is actually too long once translated in French.

I don't like the sequence of events here:

1) show useful information in the status menu

2) force a fixed, too small width on the menu

3) now the useful information doesn't fit anymore

4) declare it not useful

5) remove it

(In reply to Matthias Clasen from comment #28)
> I don't like the sequence of events here:
> 
> 1) show useful information in the status menu
> 
> 2) force a fixed, too small width on the menu
> 
> 3) now the useful information doesn't fit anymore
> 
> 4) declare it not useful
> 
> 5) remove it

The amount of time left on battery is fairly useless, which is why I mention that we should remove it. It's not shown on any mobile devices.

(In reply to Bastien Nocera from comment #29)

> The amount of time left on battery is fairly useless, which is why I mention
> that we should remove it. It's not shown on any mobile devices.

The screen size constraints of mobile device might have something to do with that...

I'm siding with Jaspers comment 11 here: I look at this information, with the knowledge that it is somewhat inaccurate, and still find it useful.

(In reply to Matthias Clasen from comment #28)
> I don't like the sequence of events here:
> 
> 1) show useful information in the status menu

We are using very different hardware then - for me "30 minutes remaining" translates to "get a plug now or be kicked off in the next five minutes", so I had to train myself to treat it as random noise that distracts from the actually useful information (the fill level).

So the core problem is that the menu bounds will always be wrong because of localizations and submenus. Fixed sizes will never work for this kind of menu design.

In a duplicate of this bug report I suggested to make the menu auto-scale. I know (as noted above) that this will make the menu jumpy when opening submenus. Isn't there a way to pre-render the menu with all submenus expanded before showing it? This width could be set as actual width for the menu (without submenus expanded).
But even this comes at a limitation: The menu width may change e.g. when plugging the power plug in while it is being displayed. So it looks like dynamically changing the width won't work very good either.

So if that doesn't work, how about using traditional menu structure, expanding submenus to the side (in this case to the left), in the same way menus work in Gtk3 and (almost) any other toolkit? This would solve all problems listed above (not limited to my comment).

(In reply to Florian Müllner from comment #31)
> (In reply to Matthias Clasen from comment #28)
> > I don't like the sequence of events here:
> > 
> > 1) show useful information in the status menu
> 
> We are using very different hardware then - for me "30 minutes remaining"
> translates to "get a plug now or be kicked off in the next five minutes", so
> I had to train myself to treat it as random noise that distracts from the
> actually useful information (the fill level).

Doesn't have to be the hardware could also be your usage pattern (i.e stable conditions vs. a varying workload).

As I've stated in the past, I would be in favour of automatically adjusting the width up to a maximum limit, in order to accommodate text that doesn't fit.

Network names will never fit, but I don't see that as being a huge issue - you can often identify the network through part of the string only, and you can always use the settings or select network dialog to see the full thing.

(In reply to Allan Day from comment #34)
> As I've stated in the past, I would be in favour of automatically adjusting
> the width up to a maximum limit, in order to accommodate text that doesn't
> fit.
> 
> Network names will never fit, but I don't see that as being a huge issue -
> you can often identify the network through part of the string only, and you
> can always use the settings or select network dialog to see the full thing.

That's what my patch does (it defines a lower and an upper bound) ... the question is how much growth we want to allow.

(In reply to Allan Day from comment #34)
> As I've stated in the past, I would be in favour of automatically adjusting
> the width up to a maximum limit, in order to accommodate text that doesn't
> fit.

So simply setting a min-width and max-width (say: 400px) as Adel's patch? Or something more sophisticated based on potential widths to avoid the menu width jumping around (e.g. when changing from "Fully charged" to "3 hours 52 minutes remaining", or when opening submenus)?

(In reply to Florian Müllner from comment #36)
> (In reply to Allan Day from comment #34)
> > As I've stated in the past, I would be in favour of automatically adjusting
> > the width up to a maximum limit, in order to accommodate text that doesn't
> > fit.
> 
> So simply setting a min-width and max-width (say: 400px) as Adel's patch? Or
> something more sophisticated based on potential widths to avoid the menu
> width jumping around (e.g. when changing from "Fully charged" to "3 hours 52
> minutes remaining", or when opening submenus)?

You tell me. Do you see a lot of jumping around with the patch?

"3 hours 52 minutes remaining" shouldn't be a string: the designs all use a short version of the time: "3:52 remaining (XX%)"

Here is a suggestion I made on irc:

- Stop fixing pixel widths. It doesn't work with translations, no matter how you pick the limit

- Never ellipsize the labels that are under our control: bluetooth, battery
- Never ellipsize the user name. That is just insulting
- For labels out of our control (wifi, vpn): Ellipsize them to the max length of the two above. Or, for extra credit, allow them to get a little longer, if that is necessary to disambiguate the current ap from the other in-range aps (for cases like somelongnetwork vs somelongnetwork_guest). Or, ellipsize in the middle.

(In reply to Allan Day from comment #37)
> You tell me. Do you see a lot of jumping around with the patch?

No, but then I set LC_MESSAGES to en_US where everything fits without ellipsization/growing ...

Florian: it doesn't fit even in en_US.UTF-8 if you use the "large text" accessibility option.

(In reply to Florian Müllner from comment #39)
> (In reply to Allan Day from comment #37)
> > You tell me. Do you see a lot of jumping around with the patch?
> 
> No, but then I set LC_MESSAGES to en_US where everything fits without
> ellipsization/growing ...

Not true. For 100% battery, you get ellipsization even in en_US

(my last comment was regarding 3.18.0, without the patch)

One further observation to throw in here:

Even if my battery label is not ellipsized atm, if I open the battery section, the string goes bold and gets ellipsized.

(In reply to Alexander E. Patrakov from comment #40)
> Florian: it doesn't fit even in en_US.UTF-8 if you use the "large text"
> accessibility option.

That's bug 754581.

(In reply to Florian Müllner from comment #39)
...
> > You tell me. Do you see a lot of jumping around with the patch?
> 
> No, but then I set LC_MESSAGES to en_US where everything fits without
> ellipsization/growing ...

I've spent some time trying to test the patch with some different locales, but I haven't had much success. I suggest that someone else has a go.

I tested it and can confirm that it avoids the ellipsization when the label goes bold. My battery is not quite at 100% atm, so I haven't tested that part yet.

I've now tested the patch in French too: no success:

0:04 avant chargement complet...

(In reply to Matthias Clasen from comment #46)
> I've now tested the patch in French too: no success:
> 
> 0:04 avant chargement complet...

So we probably should increase the max-width a bit (after all that bug existed in 3.16 too) ... 400px like Florian suggested?

(In reply to drago01 from comment #47)
> (In reply to Matthias Clasen from comment #46)
> > I've now tested the patch in French too: no success:
> > 
> > 0:04 avant chargement complet...
> 
> So we probably should increase the max-width a bit (after all that bug
> existed in 3.16 too) ... 400px like Florian suggested?

sounds like an ok solution for 3.18.1

Comment on attachment 312083 [details] [review]
aggregate-menu: Allow adjusting of the menu width

OK pushed that with max-width set to 400 .. leaving the bug open for better ideas / solutions for 3.20.

Created attachment 312675 [details] [review]
box-layout: Support replacing layout manager

There is nothing preventing callers from replacing the internal
layout manager, and as long as the replacement is a (or derives
from) ClutterBoxLayout, everything should work fine except for
losing a bit of automatic property mapping - and the latter is
easily fixable by moving the setup out of the constructor.

Created attachment 312676 [details] [review]
aggregateMenu: Ignore ellipsizable items in width-request

Some labels in the system status menu - namely network names - are out
of our control, and may thus grow the width "infinitively" unless we
restrict the menu width. So far we have been doing this by setting a
fixed width or max-width, but any value we put there might end up
being too restrictive in some locales. Instead, request a width that
fits all the labels we want to show unellipsized and use that instead
of an arbitrary limit.

Created attachment 312677 [details] [review]
aggregate-menu: Drop max-width

The menu now only considers labels we don't want ellipsized for its
width request, which already sufficiently limits the width. Plus
even a generous max-width cannot guarantee that we don't end up
ellipsizing "essential" labels in some locales.

(In reply to Florian Müllner from comment #51)
> Created attachment 312676 [details] [review] [review]
> aggregateMenu: Ignore ellipsizable items in width-request

This basically implements the suggestion from comment #38 - if we can agree on the approach, I don't think it has to wait for 3.20.

*** Bug 756408 has been marked as a duplicate of this bug. ***

Review of attachment 312676 [details] [review]:

LGTM

::: js/ui/panel.js
@@ +660,3 @@
+        if (!params)
+            params = {};
+        params['orientation'] = Clutter.Orientation.VERTICAL;

params = Params.parse (params, {orientation: Clutter.Orientation.Vertical});?
Feel free to ignore.

Review of attachment 312676 [details] [review]:

LGTM

::: js/ui/panel.js
@@ +660,3 @@
+        if (!params)
+            params = {};
+        params['orientation'] = Clutter.Orientation.VERTICAL;

params = Params.parse (params, {orientation: Clutter.Orientation.Vertical});?
Feel free to ignore.

Review of attachment 312676 [details] [review]:

LGTM

::: js/ui/panel.js
@@ +660,3 @@
+        if (!params)
+            params = {};
+        params['orientation'] = Clutter.Orientation.VERTICAL;

params = Params.parse (params, {orientation: Clutter.Orientation.Vertical});?
Feel free to ignore.

Review of attachment 312676 [details] [review]:

LGTM

::: js/ui/panel.js
@@ +660,3 @@
+        if (!params)
+            params = {};
+        params['orientation'] = Clutter.Orientation.VERTICAL;

params = Params.parse (params, {orientation: Clutter.Orientation.Vertical});?
Feel free to ignore.

Review of attachment 312675 [details] [review]:

Makes sense

Review of attachment 312677 [details] [review]:

this can make the menu going offscreen in small resolutons right?

I guess we should care about other things as well if we take into consideration such small displays... so LGTM

Comment on attachment 312677 [details] [review]
aggregate-menu: Drop max-width

Attachment 312677 [details] pushed as 83b896b - aggregate-menu: Drop max-width

Attachment 312675 [details] pushed as 508e751 - box-layout: Support replacing layout manager
Attachment 312676 [details] pushed as f8e5e3e - aggregateMenu: Ignore ellipsizable items in width-request

(In reply to Carlos Soriano from comment #58)
> +        if (!params)
> +            params = {};
> +        params['orientation'] = Clutter.Orientation.VERTICAL;
> 
> params = Params.parse (params, {orientation: Clutter.Orientation.Vertical});?

Sorry, meant to comment earlier - it doesn't really matter because we don't pass any params at all, but the two are subtly different:
The former enforces a vertical orientation, even when passing a different orientation in params. The latter sets a default orientation, but allows overriding via params. Given that the get_preferred_width() implementation doesn't make any sense for a horizontal layout, forcing the orientation looked better to me - an alternative would be to implement both width and height vfuncs and chain up to the parent according to the orientation, but then we know the orientation we're gonna use, so that'd be a bit pointless.


(In reply to Carlos Soriano from comment #60)
> this can make the menu going offscreen in small resolutons right?

I doubt any of the translations exceeds the previous max-width which was fairly generous. That leaves the username, which may indeed grow the menu beyond the available screen width - but then, there are only so many people called "Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Freiherr von und zu Guttenberg", so *shrug*.

*** Bug 756740 has been marked as a duplicate of this bug. ***

Created attachment 315349 [details] [review]
power: Stop making time estimates when discharging

Any time estimates we can come up with are notoriously unreliable;
even on devices that report correct discharging rates, any change
in workload, screen brightness etc. can throw our estimate off.

So instead, limit ourselves to only show the current percentage when
discharging and leave its interpretation to the user.

As an added bonus, we end up with shorter strings that are less likely
to cause problems with ellipsization when translated.

(In reply to Bastien Nocera from comment #65)
> Created attachment 315349 [details] [review] [review]
> power: Stop making time estimates when discharging

This is an update of attachment 312101 [details] [review]. Not sure whether we want to carry on showing charging rates, but I've simplified the code thinking that we should show it, as it's mostly reliable. I'm fine with removing it as well.

(In reply to Bastien Nocera from comment #65)
> Created attachment 315349 [details] [review] [review]
> power: Stop making time estimates when discharging
> 
> Any time estimates we can come up with are notoriously unreliable;
> even on devices that report correct discharging rates, any change
> in workload, screen brightness etc. can throw our estimate off.
> 
> So instead, limit ourselves to only show the current percentage when
> discharging and leave its interpretation to the user.
> 
> As an added bonus, we end up with shorter strings that are less likely
> to cause problems with ellipsization when translated.

Please don't remove the time estimates. I find it very useful, even though I'm aware that depending on the load this value can change.

As for the labels: there are some (like mobile broadband) which are much longer anyway

(In reply to Michael Biebl from comment #67)
> (In reply to Bastien Nocera from comment #65)
> > Created attachment 315349 [details] [review] [review] [review]
> > power: Stop making time estimates when discharging
> > 
> > Any time estimates we can come up with are notoriously unreliable;
> > even on devices that report correct discharging rates, any change
> > in workload, screen brightness etc. can throw our estimate off.
> > 
> > So instead, limit ourselves to only show the current percentage when
> > discharging and leave its interpretation to the user.
> > 
> > As an added bonus, we end up with shorter strings that are less likely
> > to cause problems with ellipsization when translated.
> 
> Please don't remove the time estimates. I find it very useful, even though
> I'm aware that depending on the load this value can change.

They might be useful to you, but they're confusing to the majority, and wildly inaccurate. Either you can find a way to make that accurate, or you can re-add that as an extension. The only question is whether or not we want to keep the (mostly accurate) charging estimates.

> As for the labels: there are some (like mobile broadband) which are much
> longer anyway

That's a good reason to fix the mobile broadband strings, not to leave the power ones untouched.

(In reply to Bastien Nocera from comment #68)
> (In reply to Michael Biebl from comment #67)
> > (In reply to Bastien Nocera from comment #65)
> > > Created attachment 315349 [details] [review] [review] [review] [review]
> > > power: Stop making time estimates when discharging
> > > 
> > > Any time estimates we can come up with are notoriously unreliable;
> > > even on devices that report correct discharging rates, any change
> > > in workload, screen brightness etc. can throw our estimate off.
> > > 
> > > So instead, limit ourselves to only show the current percentage when
> > > discharging and leave its interpretation to the user.
> > > 
> > > As an added bonus, we end up with shorter strings that are less likely
> > > to cause problems with ellipsization when translated.
> > 
> > Please don't remove the time estimates. I find it very useful, even though
> > I'm aware that depending on the load this value can change.
> 
> They might be useful to you, but they're confusing to the majority

Says who? I don't find any real evidence to back up this claim.

(In reply to Michael Biebl from comment #69)
<snip>
> Says who? I don't find any real evidence to back up this claim.

Says me. That's the reason why we removed it from the Power Settings in the first place, because the values were utterly bogus and people were like "hey, this stuff's broken".

(In reply to Bastien Nocera from comment #70)
> (In reply to Michael Biebl from comment #69)
> <snip>
> > Says who? I don't find any real evidence to back up this claim.
> 
> Says me. 

Ok, so no real data to back up this claim. As I thought.

(In reply to Michael Biebl from comment #71)
> (In reply to Bastien Nocera from comment #70)
> > (In reply to Michael Biebl from comment #69)
> > <snip>
> > > Says who? I don't find any real evidence to back up this claim.
> > 
> > Says me. 
> 
> Ok, so no real data to back up this claim. As I thought.

People filing bugs isn't real data?

(In reply to Bastien Nocera from comment #72)
> (In reply to Michael Biebl from comment #71)
> > (In reply to Bastien Nocera from comment #70)
> > > (In reply to Michael Biebl from comment #69)
> > > <snip>
> > > > Says who? I don't find any real evidence to back up this claim.
> > > 
> > > Says me. 
> > 
> > Ok, so no real data to back up this claim. As I thought.
> 
> People filing bugs isn't real data?

links?

I'd like to echo the same concern that was raised in
https://bugzilla.gnome.org/show_bug.cgi?id=708472#c28

(In reply to Michael Biebl from comment #73)
> I'd like to echo the same concern that was raised in
> https://bugzilla.gnome.org/show_bug.cgi?id=708472#c28

The width issue has been fixed according to the suggestion in comment #38. So no, this has nothing to do with removing information to fit some fixed width, it's about keeping the reliable bit (percentage) and dropping the unreliable one (time estimate).

While percentage is certainly "reliable", it's also useless and not what people want to know. I want to know how long I can keep using my laptop.
That the time remaining changes depending on the load is actually want I want to know.

See it from a different perspective: No navigation software removes the time-to-arrival and only displays distance-to-arrival, because time-to-arrival is "unreliable" due to external influences.

I often use my laptop in places I cannot easily plug it in, and I want to get the most out of it. I don't think I've ever used the percent meaningfully, either.

My phone has survived for hours on 1%, and other times it's died in a few minutes. The latest Android actually adds estimates, which I can use.

I also would like to add, that as maintainer of GNOME in Debian, I don't remember a single bug report where a user was confused by the time remaining displayed in gnome-shell. So I have a hard time believing that this is "confusing to the majority".
What I can tell you though with absolute certainty is, that we will have users which will miss this useful feature. Me included.

(In reply to Bastien Nocera from comment #70)
> (In reply to Michael Biebl from comment #69)
> <snip>
> > Says who? I don't find any real evidence to back up this claim.
> 
> Says me. That's the reason why we removed it from the Power Settings in the
> first place, because the values were utterly bogus and people were like
> "hey, this stuff's broken".

The fact that (In reply to Bastien Nocera from comment #72)
> (In reply to Michael Biebl from comment #71)
> > (In reply to Bastien Nocera from comment #70)
> > > (In reply to Michael Biebl from comment #69)
> > > <snip>
> > > > Says who? I don't find any real evidence to back up this claim.
> > > 
> > > Says me. 
> > 
> > Ok, so no real data to back up this claim. As I thought.
> 
> People filing bugs isn't real data?

It's possible at the same time that:

 - The provided time estimates are useful to people
 - The provided estimates are sometimes inaccurate enough so that people file bugs

And even if we can't fix this - if time estimates *will* always cause people to file bugs - we might want to leave them there. We're not maintaining GNOME to minimize the number of bug reports ... that isn't the end goal.

@Michael Biebl - so I think what Bastien is trying to say here - what is the point of having information that is completely unreliable, so even if you have 1% battery does it really mean you have one percent?  I think Jasper gave a data point that varies wildly based on that number.

As for your excellent example of 'time to arrival', it is a strong point, but I think the difference is that the 'time to arrival' is updated continuously as you go through traffic and what not.  I know what you mean as well.  That information is still useful to you, because it at least tells you how much the traffic or accident has delayed you.

In this case,  it is like saying GPS is unreliable.  We need to fix GPS to be more reliable.  So the real work here is to figure out how to make power consumption reliable enough that we can forecast accurately.  I think you'll find that internally, you've looked at that number and made your own set of risk assessments.  But what would you feel if that number was truly accurate?

What would you feel if you had current consumption rate?  Would you be able to extrapolate something from that?

Anyways, I hope I have stated things accurately, Bastien.

(also thank you for all your work in Debian, grateful it)

(In reply to Sri Ramkrishna from comment #79)
> So the real work here is to figure out how to make power consumption reliable [..]

That's not possible power consumption varies between workloads. That's physics we can't change that.

The "time remain" figure is, has and always will be just an estimate. Nothing more nothing less (maybe we should make hat more clear) ... so lets just move on.

Pushed as 6c08799 - power: Stop making time estimates

Happy to know that a number of us were overruled on an unreviewed patch and simply pushed directly. Thanks for the kind discussion and taking our feedback into account.

(In reply to Jasper St. Pierre from comment #82)
> Happy to know that a number of us were overruled on an unreviewed patch and
> simply pushed directly. Thanks for the kind discussion and taking our
> feedback into account.

The patch was a later version of attachment 312101 [details] [review], which was marked as acn.

A patch which the reviewer later obsoleted in favor of a new approach. Obsoleting a patch obsoletes the review for it.

(In reply to Jasper St. Pierre from comment #84)
> A patch which the reviewer later obsoleted in favor of a new approach.

Nope, I obsoleted it when I committed the patch. Verify here:

Anything else?

(In reply to Bastien Nocera from comment #83)
> which was marked as acn.

It was, but that was before Matthias and others raised their objections. So I still consider this an open question, and like the design team to join in.


(In reply to Jasper St. Pierre from comment #84)
> A patch which the reviewer later obsoleted in favor of a new approach.

No, it wasn't obsoleted - the rationale for the patch is that it presents an unreliable estimate as fact (based on comment #10), not to force a label to an arbitrarily picked menu width.

(In reply to Florian Müllner from comment #86)
> (In reply to Bastien Nocera from comment #83)
> > which was marked as acn.
> 
> It was, but that was before Matthias and others raised their objections. So
> I still consider this an open question, and like the design team to join in.

Feel free to revert if you think it was committed in error. FWIW, the time estimates have long (couple of release cycles) been removed from the control-center, and I've just flipped the switch on UPower's time-based policies, in favour of percentage based policies.

(In reply to Bastien Nocera from comment #87)
> Feel free to revert if you think it was committed in error.

I think it was committed prematurely, not necessarily in error (depending on the conclusion). Reverting it before coming to a conclusion looks equally premature to me, so meh :-)

(In reply to Bastien Nocera from comment #87)
> (In reply to Florian Müllner from comment #86)
> > (In reply to Bastien Nocera from comment #83)
> > > which was marked as acn.
> > 
> > It was, but that was before Matthias and others raised their objections. So
> > I still consider this an open question, and like the design team to join in.
> 
> Feel free to revert if you think it was committed in error. FWIW, the time

Ok, I did so.

> It was, but that was before Matthias and others raised their objections. So I > still consider this an open question, and like the design team to join in.

Please don't give my opinion too much weight here. Lately, time estimates on my system have really gone downhill, from 'slightly inaccurate' to 'best ignored'. Maybe my battery is dying.

(In reply to Matthias Clasen from comment #90)
> Please don't give my opinion too much weight here. Lately, time estimates on
> my system have really gone downhill, from 'slightly inaccurate' to 'best
> ignored'. Maybe my battery is dying.

Your computer is not the only one out there with unreliable battery life estimates; your opinion deserves weight.

Honestly, I think the harm of providing inaccurate information significantly outweighs the benefit of this feature, but it's a trade-off and understandably some folks will feel differently. It would be lovely to guarantee relatively-accurate estimates, but we can't, so....

*** Bug 756408 has been marked as a duplicate of this bug. ***

After reading https://gitlab.gnome.org/GNOME/gnome-shell/issues/996 I noticed that the strings are not ellipsized anymore. Can we close this issue here?

(In reply to Alexandre Franke from comment #93)
> After reading https://gitlab.gnome.org/GNOME/gnome-shell/issues/996 I
> noticed that the strings are not ellipsized anymore. Can we close this issue
> here?

Looks like it, yes. I don't see any ellipsis at all. Let's hope the fix for https://gitlab.gnome.org/GNOME/gnome-shell/issues/996 will not bring this issue back.