Bug 485846

The sliders inferred an absolute scale, which isn't what people wanted. I changed them some time a go to be relative, but this just confused everybody. What we've got in the UI now covers all of the use cases -- changing the backlight level using the keys and brightness applet, and ambient light sensor, and with docked/not-docked policy all work as they should.

(In reply to comment #1)
> The sliders inferred an absolute scale, which isn't what people wanted.

Sure? Did people complain about it or did you get any bug reports? If so, please show me.

Sure, I got loads of bugzillas, search in gnome bugzilla for brightness under the component gnome-power-manager. Quite a few people got confused about what interaction is happening, and what should happen.

IMO there should not be any interaction, people should be able to set both levels independently. If there was confusion, it was most likely caused by fuzzy descriptions and changing the behavior in every release.

I searched 137 bug reports in Gnome bugzilla and didn't find a complainant about the battery slider with absolute scaling. In fact I found:

http://bugzilla.gnome.org/show_bug.cgi?id=509211#c4
http://bugzilla.gnome.org/show_bug.cgi?id=483134#c5
"- AC and battery settings MUST not interact with each other
- the battery *brightness*slider* should be *brought*back* (one should be able
to set the default battery brightness level, no matter what automatic dimming
effect is added)"

http://bugzilla.gnome.org/show_bug.cgi?id=542742
"What I really miss in that dialog are the settings for:
...
- the level of brightness when "reduce backlight brightness" is active
  (IIRC that was available in some former version of gpm)"

http://bugzilla.gnome.org/show_bug.cgi?id=489176
"The display brightness slider in the "On AC Power" tab measures brightness, but
the same slider in the "On Battery Power" tab measures how much to dim the
display. This is confusing."
Then you switched to the checkbox and the reply you got was:
"I think that would be better simply set all sliders to select brightness value,
not dim. This would be very clear and would still allow users to easily change
the value without having to use gconf-editor (I think that changing brightness
value shouldn't be considered as a "power user" task)"

http://bugzilla.gnome.org/show_bug.cgi?id=548626
"The UI for brightness control (the slider) in inconsistent. In the tab "On AC
Power" its label is "Set display brightness to:", and 0% means very dim and
100% means very bright.
The problem is that in the tab "On Battery Power", the numbers are opposite.
The label is "Dim display brightness by:", and 0% means very bright and 100%
means very dim.

I think this is counter intuitive and should be changed."

This is a complainant on the relative brightness_dim_battery slider, but if someone complains that the two sliders are inconsistent the solution is to make them both absolute instead of removing one.

In case I have overlooked a bug report please tell me.

If you look at what the _point_ of the power manager is (to save power, and still allow you to use your computer like normal) then you'll probably agree with the new UI choices.

>people should be able to set both levels independently

Statements like that make me laugh.

* What if the level on battery it higher the level on AC? Do we go /up/ in brightness when we disconnect from a dock?
* What if we're using a ambient light device to scale the brightness -- do we change the absolute values, the policy value, or the user value?
* What if we dim the panel to a preset level, and then the user moves the mouse -- do we return to the "policy" brightness, or the "user brightness" which can be changed with the brightness slider and the hotkeys?
* If we change the policy brightness and the user brightness is different, do we use a new absolute value (overriding the user brightness) or just ignore the change?

People claiming to know what's best for the UI have little understanding of what g-p-m is trying to do, or the complexity involved. I also don't change things between releases on a whim, or on the toss of a coin. I'm always trying to make this stuff work right, and also work with ever changing kernel and X internals.

(In reply to comment #5)
> If you look at what the _point_ of the power manager is (to save power, and
> still allow you to use your computer like normal) then you'll probably agree
> with the new UI choices.

First of all g-p-m should allow people to _manage_ power, not necessarily to _save_ it. It's the user's decision whether he wants to save power or if he has other needs.

> >people should be able to set both levels independently
> 
> Statements like that make me laugh.
> 
> * What if the level on battery it higher the level on AC? Do we go /up/ in
> brightness when we disconnect from a dock?

Then it's the user's choice, because he configured it that way. Maybe he uses his laptop outdoor and needs a brighter display there?

> * What if we're using a ambient light device to scale the brightness -- do we
> change the absolute values, the policy value, or the user value?

The user value. Usually user prefs overwrite system prefs, that's how it has always been on Linux, so people most likely expect that behaviour.

> * What if we dim the panel to a preset level, and then the user moves the mouse
> -- do we return to the "policy" brightness, or the "user brightness" which can
> be changed with the brightness slider and the hotkeys?

User brightness. Besides that I don't see how this is connected to this bug report.

> * If we change the policy brightness and the user brightness is different, do
> we use a new absolute value (overriding the user brightness) or just ignore the
> change?

Ignore and use user brightness, see above. This also is not connected to this bug, because it can even happen with your current design.

> People claiming to know what's best for the UI have little understanding of
> what g-p-m is trying to do, or the complexity involved.

Developers claiming to know best what users want without actually listening to their needs seem to understand little of usability. You said there were "loads of bugzillas", so please be so kind as to show me any complainants about the absolute sliders.

> things between releases on a whim, or on the toss of a coin. I'm always trying
> to make this stuff work right, and also work with ever changing kernel and X
> internals.

Richard, I know you are working hard and I appreciate that very much. Nevertheless I think the old behavior was better from a user's p. o. v.

Simple +1 to Christoph. With respect to comment #1, but you don't have any
clue what I am as user expecting ;-) So please not CLOSED/NOTABUG again, it
is a valid bug report. A power manager doesn't need to save power all the
time, but to make stuff configurable - a possibility which got taken here...

(In reply to comment #7)
> you don't have any clue what I am as user expecting

I guess as upstream maintainer for 4 years, I've got no idea at all.

> A power manager doesn't need to save power all the
> time, but to make stuff configurable

Sorry, but the whole point of gnome-power-manager is to save power without getting in the way of what the user wants to do. It's not going to let you set the "performance" governor any more than it lets you increase the brightness on battery.

When you've read the design documents, read the code, understand what interactions are needed, and posted patches, please re-open this bug report. 

Until then, I would appreciate it if you didn't tell me what to do with bugs assigned to me. Thanks.

I don't doubt, that you've a deep technical understanding of this package, but
"just" being upstream maintainer does definately not mean, that you always know 
what usability means and what users are really expecting, sorry. Otherwise we
would not be at this unlucky point or better said, we even would not have this 
bug report.

If the whole point of gnome-power-manager is to save power all the time, I ask
you hereby to rename the package ASAP to gnome-power-saver or similar. A manager
manages resources and not only saves and keeps resources. This is what a human
manager usually should do as well, when comparing it with a real life example.

I think, Christoph is still and patiently waiting for some answers regarding 
comment #6 as well, which I'm interested in, too.

(In reply to comment #9)
> If the whole point of gnome-power-manager is to save power all the time, I ask
> you hereby to rename the package ASAP to gnome-power-saver or similar.

Sorry, no, that's ridiculous.

> A manager manages resources and not only saves and keeps resources. This is 
> what a human manager usually should do as well, when comparing it with a
> real life example.

I think it's a bad analogy, but I'll run with it: Would a manager let you use more resources than you need to - just because you want to? The manager is always trying to reduce the amount of resources used, not promoting wasting them.

> I think, Christoph is still and patiently waiting for some answers regarding 
> comment #6 as well, which I'm interested in, too.

There are alternatives to gnome-power-manager -- kpowersave, guidance-power-manager, heck, you could even fork the sources and create something new. KPowerSave in particular allows you to tweak every value and policy imaginable, which will allow you do do anything. Ohh, and the UI is a disaster for inexperienced admins, and those that just want things to "just work", but that's the price you pay for having everything configurable.

Why do try to suggest me using kpowersave for GNOME if you made gnome-power-
manager unusable for exactly that just because of obvious usability reasons?

Well, that depends on the manager: A clever and intelligent manager allows to
e.g. discuss about the situation and what makes sense not only to him, but
also to others and has a look to the overall benefit. Looks like your picture
of a manager is limited to very less than that, unluckily. And especially when
looking to the GNOME and Open Source community, we should be open to accept
reasonable and valid input and not just refuse it with strange reasons, sorry.

And your reply is still not an answer for comment #6 from Christoph. Maybe he
expects an answer, I still would be interested in that reply.

(In reply to comment #5)

> * What if the level on battery it higher the level on AC? Do we go /up/ in
> brightness when we disconnect from a dock?

Yes! Please allow me to do this.

When my laptop is docked, I'm sitting in my dark, windowless basement where too much brightness hurts my eyes. 

When my laptop is on battery I'm often on a train and want as much brightness as possible. I know that this drains the battery faster but when I have to choose between longer battery life and being able to read the display I choose a).

(In reply to comment #10)
>
> I think it's a bad analogy, but I'll run with it: Would a manager let you use
> more resources than you need to - just because you want to? The manager is
> always trying to reduce the amount of resources used, not promoting wasting
> them.

(No, that's the controlling guys ;))
Richard, I'm pretty sure your manager let's you work the way _you_ want, because he knows that you are much more productive if he doesn't force you to work in the dark.

> There are alternatives to gnome-power-manager -- kpowersave,
> guidance-power-manager, heck, you could even fork the sources and create
> something new. 

guidance-power-manager is dead, no release for nearly two years. Kpowersave is no alternative, because it requires tons of KDE stuff. Glad I imported xfce4-power-manager into rawhide last week, but telling people to use something else or even to fork from your project is not the way of dealing with usability questions.


Please let me sum up the discussion from my p. o. v.:
You said that you had "loads of bugzillas" but you were not able (or willing) to show at least one complainant about the absolute slider. I dug through all g-p-m bugs that mention the word "brightness" and didn't find a complainant ether, but in fact I found at least 4 people complaining you removed the slider.

In comment # 5 you listed 4 reasons against my proposal, but 3 of your points have nothing to do with the problem and still occur with your current design. 

The only valid question was the first one: What if brightness level on battery is configured higher than on AC? But is this a bug at all? If it is, then it's not g-p-m but the user who configured it. And perhaps the user has good reasons to do so: I often use my laptop on the train. The ride only takes an hour, so I don't need to care for the battery. But I do need a bright display there, because the surrounding is really bright and my display pretty bad.


Richard, I really appreciate your work, I can imagine that it's not easy to work around broken BIOSes or strange ACPI events etc. Nevertheless this has nothing to do with the design of gnome-power-preferences. g-p-m should enable the people to do what they want but not what a developer thinks is best for them. So please be so kind as to pay attention to the user's needs and rethink your decision.

Before you close this bug again please show me a single report where somebody complained about the absolute sliders. And if you are going to close it again, please close it WONTFIX instead of NOTABUG, because it's a regression, so it surely _is_ a bug.

(In reply to comment #13)
> Before you close this bug again please show me a single report where somebody
> complained about the absolute sliders. And if you are going to close it again,
> please close it WONTFIX instead of NOTABUG, because it's a regression, so it
> surely _is_ a bug.

I'm sorry guys, I don't have any more time for your silly games.

Please see:

* http://bugzilla.gnome.org/buglist.cgi?query=brightness
* https://bugzilla.redhat.com/buglist.cgi?query_format=specific&product=Fedora&content=brightness
* https://bugs.launchpad.net/bugs/+bugs?field.searchtext=brightness&search=Search+Bug+Reports&field.scope=all&field.scope.target=gnome-power-manager

I've really not got time to search though each relevant one and write a paragraph in explanation of every bugzilla.

If you open this bug again, I'm not going to close it, I'll just add 485846 to my email killfile. It's not like I'm going to get pressured from my boss to work on this if it's been opened a specific number of days.

Software isn't designed by committee where you have to rationalise every decision before you take it. Software is a vision, and I'm writing g-p-m to that grand plan. If you don't like it that's fine. Thanks.

(In reply to comment #14)
<SNIP>
> If you open this bug again, I'm not going to close it, I'll just add 485846 to
> my email killfile. It's not like I'm going to get pressured from my boss to
> work on this if it's been opened a specific number of days.

So is this confirmation that there is in fact a cabal and that Fedora is 100%
powered by the Red Hat agenda? Is that what you're saying here? .... just want
clarification that that's actually what's being said here. K thnx.

> 
> Software isn't designed by committee <SNIP>

Maybe that's the problem ...


# Yes, you will call me a troll and maybe I am a little .... but you could
# maybe, just *maybe* be less of an ass.

Happy hacking,
-AdamM

(In reply to comment #15)
> (In reply to comment #14)
> <SNIP>
> > If you open this bug again, I'm not going to close it, I'll just add 485846 to
> > my email killfile. It's not like I'm going to get pressured from my boss to
> > work on this if it's been opened a specific number of days.
> 
> So is this confirmation that there is in fact a cabal and that Fedora is 100%
> powered by the Red Hat agenda? 

No, don't be silly.

> > Software isn't designed by committee <SNIP>
> 
> Maybe that's the problem ...

There is not one successful software project that's run by a committee.

Richard.

If you want to code your own sh*t, cool, but stay away from reasonable community projects like Gnome that try to actually give the users what they require and not what you think of as a vision.

Fedora is becoming the My Little Pony distro.