Red Hat Bugzilla – Full Text Bug Listing
|Summary:||brightness_dim_battery missing from gnome-power-preferences|
|Product:||[Fedora] Fedora||Reporter:||Christoph Wickert <cwickert>|
|Component:||gnome-power-manager||Assignee:||Richard Hughes <richard>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||andreas, fucku, maxamillion, redhat-bugzilla, rhughes, richard, sven|
|Target Milestone:||---||Keywords:||Regression, Reopened|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-02-26 03:17:58 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Christoph Wickert 2009-02-16 19:10:11 EST
Description of problem: With previous versions of g-p-m one could set brightness for AC and battery independently through sliders. With g-p-m 2.24.x one can no longer do this. One can only select the brightness for AC and choose to reduce backlight brightness on battery or not (/apps/gnome-power-manager/backlight/battery_reduce). Looking with gconf-editor I see both /apps/gnome-power-manager/backlight/brightness_ac and /apps/gnome-power-manager/backlight/brightness_dim_battery So why can one not set brightness_dim_battery through gnome-power-preferences any longer? This is a loss of functionality and surely a regression. Version-Release number of selected component (if applicable): gnome-power-manager-2.24.4-1.fc10.i386, but affects the complete 2.24.x series.
Comment 1 Richard Hughes 2009-02-17 03:48:27 EST
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.
Comment 2 Christoph Wickert 2009-02-19 17:41:26 EST
(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.
Comment 3 Richard Hughes 2009-02-20 04:16:49 EST
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.
Comment 4 Christoph Wickert 2009-02-20 06:47:07 EST
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.
Comment 5 Richard Hughes 2009-02-20 07:34:18 EST
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.
Comment 6 Christoph Wickert 2009-02-20 08:43:29 EST
(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.
Comment 7 Robert Scheck 2009-02-22 15:59:22 EST
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...
Comment 8 Richard Hughes 2009-02-23 03:42:55 EST
(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.
Comment 9 Robert Scheck 2009-02-23 05:05:04 EST
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.
Comment 10 Richard Hughes 2009-02-25 04:22:04 EST
(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.
Comment 11 Robert Scheck 2009-02-25 05:56:43 EST
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.
Comment 12 Sven Lankes 2009-02-25 08:18:30 EST
(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).
Comment 13 Christoph Wickert 2009-02-25 08:49:17 EST
(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.
Comment 14 Richard Hughes 2009-02-26 03:17:58 EST
(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.
Comment 15 Adam Miller 2011-07-26 15:24:02 EDT
(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
Comment 16 Richard Hughes 2011-07-27 04:34:57 EDT
(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.
Comment 17 Yura Fegott 2011-08-24 18:09:58 EDT
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.