Bug 174160

Summary: g-p-m needs work
Product: [Fedora] Fedora Reporter: Havoc Pennington <hp>
Component: gnome-power-managerAssignee: John (J5) Palmieri <johnp>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: jkeck, richard
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-12-19 19:40:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Havoc Pennington 2005-11-25 11:31:52 UTC
UI design wise, I think the combination of apm plus battstat did exactly two
things that mattered:

 - suspend on lid close
 - show how much battery is left

g-p-m/acpi seems to be a downgrade on both fronts; it defaults to "no action" on
lid close, and the icon isn't as large and clear as battstat for showing battery
status.

I understand g-p-m is doing behind-the-scenes stuff that we need, but it kind of
sucks to eat a downgrade in the two things that matter most in order to tweak
the details.

The most important fix I'd say is to suspend on lid close by default.
I can't imagine why you want this setting to be "no action" unless suspend
doesn't *work* (which it often doesn't, but we shouldn't plan to fail...)

I'd also suggest dropping the g-p-m tray icon and either keep battstat or
quickly code up something like battstat - the crazy prefs for g-p-m, if they
make sense at all, can just go in the System menu with all our other prefs. 
The prefs I'd expect here are the ones battstat has. 

g-p-m icon problems:
 - it's a tray icon and not an applet so I can't move it around
   etc.
 - the icon is less attractive and less informative
   than the battstat one; it's both too big for a tray
   icon and too small to effectively show battery state
 - I don't know or care what the difference between 
   Suspend and Hibernate are, I never have, never will
 - I don't want to choose whichever one from a menu, I want
   to just close the lid
 - the System menu item and dialog is just silly
 - virtually all of the preferences are also just silly
   (the battstat prefs were more "useless" but less 
    silly, imo; the g-p-m prefs have technobabble and 
    stuff I don't care about, battstat prefs were fun 
    at least)
 - even if the prefs aren't silly they go in the System
   menu, not on an applet that appears to be a power meter

Anyway, turn off the tray icon by default, suspend on lid close by default, and
keep battstat and I think it'd be about perfect.

Comment 1 Richard Hughes 2005-11-25 11:56:31 UTC
With regard to the "suspend on lid close" -- then this is a valid point. My
laptop only resumes about 9 out of 10 times, so I have suspend turned off in
case I shut the lid and loose my work. I figured that was 'safer' from a
bugzilla perspective. You can convince me I'm wrong, and I'll change this
upsteam, or you can just patch one gconf key from "nothing" to "suspend" :-)

As for the icons, well, they are replacable to whatever you like, but I was
constrained with the GNOME people wanting square icons. Also, you probably using
an old version with the old icon style as stuff tends to change quickly in CVS.

As for the difference in suspend and hibernate, there are essential differences
in my opinon. I can resume from suspend in seconds, but takes nearly half a
minute to resume from hibernate. When suspended you still use power, but not so
when hibernated. Maybe this just needs explaining. Choosing one or the other is
going to make lost of users mad. Even Windows has two "sleep" states. :-)

I agree the System menu item is silly, I wanted to display all the batteries in
the system (in detail), but at the moment it's pretty bare. I might disable this
for the next release.

And as for the applet, well the interface between g-p-m and the aforementioned
applet would get crazy and complicated. Also with an applet you are requiring
the user to manually add a new applet to the taskbar instead of an icon just
appearing when you add a battery and it "just working". You could argue the same
applet vs. notification area thing using NetworkManager -- adding another layer
of abstraction would be crazy.
Also, people tend to like that they can theme the icons in g-p-m, rather than
the hardcoded image (and colours) in battstat.

Cheers, Richard.

Comment 2 Havoc Pennington 2005-11-25 19:49:32 UTC
We're suffering in part from the whole "applets suck in one way and systray
sucks in another" thing (there's a whole design that was done to fix this -
basically making applets more like tray icons while keeping some of their
applety aspects - but don't think anyone is coding on it). Not g-p-m's fault but
thinking of the desktop as a whole it needs fixing sometime.

Someone told me what mac does about suspend/hibernate is automatically wake up
from suspend after a while and switch over to hibernate. That would be a better
solution - anytime you start trying to explain to users the difference between
two synonyms you're pretty much doomed :-P but no clue if it can be done on PC
hardware.

Anyway I think we should suspend on lid close and if someone's acpi is broken
they could play with the preferences, or just wander around with an open laptop
as I've done before when I lose the kernel roulette and suspend goes unstable... 

btw, a minor item probably not worth filing a bug is s/Power Preferences/Power/
in the menu to match the other menu items...


Comment 3 Richard Hughes 2005-11-26 12:31:57 UTC
Yes, I agree with the applets/systray thing -- when GNOME sorts out it's icon
handling then I'll use the new scheme, until then, I think I will stick with the
notification area icon.

DavidZ and I discussed resuming from suspend and then hibernating a few months
back, but the "resume timeout" functionality is heavily tied to most BIOS's, and
is very vendor specific in timeout. I don't know how much of the new ACPI stuff
tries to remedy this, but I'll have a look at the latest acpi snapshot. For mac,
this should be quite easy to do, but we would have to code this in pm-utils as
currently it's a nop.

I agree with your comment on suspend-on-lid-close, so I've committed the
required change in CVS.

As for the s/Power Preferences/Power/ change, the word 'Power' is a little short
and snappy, and perhaps not descriptive enough. I agree the word preferences
shouldn't be used tho. Got any other ideas, or is 'Power' good enough?

I also agree with your critisism that 'Power Info' is not required, at least in
it's current form. I've removed the menu item from the notification icon in CVS.

With the gnome-power-preferences, what settings are "silly"? The current CVS has
simple radio boxes to clear up the icon mess, and there are lots of GNOME HIG
updates.

Thanks for your ideas and time, I appreciate the feedback.

Richard.

Comment 4 Havoc Pennington 2005-11-26 19:07:55 UTC
On the prefs, I'd say Options and Advanced are a concession to linux geekdom (or
workarounds for power management being broken). I'm sure everyone can and will
debate me.

The one I find funny though is:
 Power button action:   powers on/off,   [anything else]
kind of like:
 M key action:          enters letter M, [anything else]

;-)

The Notification Area toggle is an artifact of the trayicon/applet breakage
(rather than this setting you want your battery charge icon to be in Add To
Panel and have a Remove menu item on it). I do think the applet is a better UI
given current limitations of the tray/applet stuff though neither is currently
ideal.

The timeouts for sleep on the first tab could just be in the screensaver 
prefs, I think they already have something similar and you want to relate them
(i.e. screensaver should not kick after a timeout longer than the suspend
timeout, whether on AC power or not - also you might want to not count suspended
time in the screensaver timeout so you don't get screensaved on unsuspend)

Anyway, I continue to feel that the Prefs menu as a whole is way out of control
so it'd be useful to combine with the screensaver app, use an applet, etc. to
relocate the important prefs and then move the rest of them to some kind of
PowerTweakUI tool; that way avoiding yet another prefs dialog in an already
far-too-huge menu.

But usually when this comes up on the list people quickly resort to "how can we
organize the prefs dialogs in the menu/control-center-shell" rather than how to
clean them up so more prefs are contextually located thus eliminating the
standalone prefs dialogs ... 

sorry, tangent ;-)

Thanks for your hard work and responsiveness, obviously it's easy for me to just
sit here and commentate.


Comment 5 Richard Hughes 2005-11-28 11:47:09 UTC
I think we 'require' the options in the preferences as power management if
different to each person, as we are trying to satisfy 100% of the new users and
at least 80% of the power-users.

And as for the M "enters M" analogy, it made me laugh, and I get your point --
but on some machines (like my Toshiba laptop) there is only a 'power' button,
and it's quite cool to be able to press that and do a hibernate, rather than
power off. Similar for lots of stuttle mini-pc's and quite a few other laptops.

As for the applet stuff, when the tray is redesigned, I *promise* I'll use the
new design :-) It's just at the moment applets cannot do what I require.

And as for merging with gnome-screensaver prefs UI, I think the distinction
between the two is very important (and a good thing). It's only because of
XScreenSaver that we expect the screensaver to be linked into the powersaving,
and I think the distinction is a good one to make. By that is just my opinion.

And re: your last comment, thanks for the praise, and the critism. Sometimes you
need someone to say the obvious! You might want to get mclasen/j5/whoever to
build CVS g-p-m for rawhide so you can see all your new changes!

Thanks, Richard.