GNOME Bugzilla – Bug 363757
When running g-p-m on a desktop, there should be no mention of batteries
Last modified: 2006-11-24 22:25:30 UTC
Please describe the problem: When running g-p-m on a desktop, there should be no mention of batteries unless they exist (as per battery-powered mice). I'm given to understand that it's actually referring to support for UPSes or peripherals with batteries. If this is the case, there ought to be "Only display when UPS or peripheral present' as an option in the Notification area, instead of "Only display when battery present". Additionally, there should be a device area for potential UPSes or peripherals in the Power Information display. Steps to reproduce: 1. Open g-p-m prefs and info on a desktop machine. Actual results: References to a battery, instead of a UPS or peripheral, and no way to check on the state of an attached UPS or peripheral. Expected results: Should either talk about UPSes or peripherals, or completely forgo those sections, similarly to the loss of the running on battery section (although, if UPS is replacing the idea of a battery, perhaps a running on UPS tab would make sense?) Does this happen every time? Seems to, on desktops. Other information:
Agreed. This should be a fairly simple change... I might get a chance to make a patch for it tomorrow. Since the preferences panel already hides one of the tabs if we are in desktop mode / don't have a battery, it should be a fairly simple change.
(In reply to comment #0) > Please describe the problem: > When running g-p-m on a desktop, there should be no mention of batteries unless > they exist (as per battery-powered mice). I'm given to understand that it's > actually referring to support for UPSes or peripherals with batteries. If this > is the case, there ought to be "Only display when UPS or peripheral present' as > an option in the Notification area, instead of "Only display when battery > present". > > Additionally, there should be a device area for potential UPSes or peripherals > in the Power Information display. There should be already, what do you get? > Steps to reproduce: > 1. Open g-p-m prefs and info on a desktop machine. > > Actual results: > References to a battery, instead of a UPS or peripheral, and no way to check on > the state of an attached UPS or peripheral. Have you got a screenshot, I'm a little confused. > Expected results: > Should either talk about UPSes or peripherals, or completely forgo those > sections, similarly to the loss of the running on battery section (although, if > UPS is replacing the idea of a battery, perhaps a running on UPS tab would make > sense?) You might want to check out CVS head and see what I've done there. Thanks, Richard.
Created attachment 75414 [details] Screenshot of single-tab info screen and general screen which mentions displaying on battery present
Ahh, I see what you mean, thanks for the screenshot. The reason this optionbox is displayed is that by default we on show the icon when the battery is present so that if you added a battery the icon would show. The correct fix would be to split the ->present battery field into ->missing_from_bay and ->has_hardware as this would fix the problem in a sane way. Does this make sense?
Created attachment 76131 [details] GTK Widget Hide All bug? I was going to go after some low hanging fruit and disable the empty battery frames I'm seeing on my machine, but I think there is a gtk+ bug blocking me. Just wanted to make sure I'm not misunderstanding something about how we set up the preferences before I go post this as a bug against gtk. I added a debug statement to check that the line is running, and to check that the "no_show_all" property was set to 0.
Stu, you are referring to the 2.17 UI, which has indeed a bug that I've just fixed (using the same widget name twice). Suzanne is using 2.16. Richard.
(In reply to comment #4) > The correct fix would be to split the ->present battery field into > ->missing_from_bay and ->has_hardware as this would fix the problem in a sane > way. So we would report has_hardware if there is a battery bay, and missing_from_bay if that bay is empty? I think we should probably keep calling `missing_from_bay` as `present` to avoid a double negative. I'd like to give this one a try, if you don't mind Richard.
Sure, but I think we need to be very careful with gconf defaults, for instance, if you share your gconf key in an enterprise with your desktop and your laptop, having no battery option not in the ui would prevent you setting charging (and would force either never or always) every time you use g-p-p on the desktop machine. Ideas how to prevent this welcome. Richard. p.s. you got commit yet?
Created attachment 76241 [details] Split the notification options to Battery and AC No commit rights yet =/ Following the pattern in the rest of the Preferences tabs, what do you think of this layout? I haven't done any work with gconf, so I don't know what kind of dance we'd have to do to convert old configurations, but I think this is much clearer. In this configuration, we can safely enable the Battery area if "->missing_from_bay or ->has_hardware", and otherwise we'll disable it. On a related subject, the HIG recommends that instead of hiding options in Preferences dialogs, it is more discoverable to make them insensitive. What do you think: should I file a seperate bug/patch to make all of our battery sections insensitive instead of hidden? http://developer.gnome.org/projects/gup/hig/2.0/controls-sensitivity.html
I have a nearly finished patch for this, but I obviously had to make some string changes. I've never dealt with gettext or .po files before, so I'd love it if you could walk me through how to apply my changes when you get the chance. #hal tonight after 9pm your time? Thanks Richard ps. Still no commit.
2006-11-24 Richard Hughes <richard@hughsie.com> * src/gpm-prefs-core.c: (prefs_setup_notification): Hide the 'When battery present' option when there is no primary batteries or UPS's in the system. This does mean neither option will be selected in the GUI for desktop PC's from first-install, which is why a better solution should probably be found. Fixes #363757