Re: [gpm] Limiting inhibition by applications

[Victor Lowther <victor lowther gmail com>]

On Fri, 2008-11-28 at 23:39 +0100, Milan Bouchet-Valat wrote:
> Hi!
> 
> In recent GNOME versions, more and more applications use D-Bus to
> inhibit suspend and hibernate when they're working on tasks that should
> not be interrupted. This is great and I love how this communication
> system works.
> 
> However, at least since 2.24, manual suspend (as opposed to
> automatically trigger by inactivity) is forbidden when an application
> has told g-p-m to inhibit this action. This results in a nice
> notification explaining (very well designed) who and why.
> 
> IMHO this is a little too much: for example, I'm using Transmission in
> the background, and it logically prevents the system from suspending
> automatically, so that downloading is not stopped. But sometimes I want
> to hibernate, and restart my computer later, and I'd like my downloads
> to resume then. But g-p-m forbids me to do so, and I'm forced to stop
> manually Transmission before hibernating, thus I need to restart it
> later, and it reduces the interest of hibernate/suspend.

Transmission even inhibits the screen from blanking or entering any VESA
powersaving modes -- I guess displaying bittorrent status updates is
just that important. :/

> What I think is that inhibition should not prevent users from doing
> anything. This is absolutely frustrating; instead, the desktop is here
> to work for me. So would there be an issue if we force hibernation has
> it was before? I can imagine it may be complex: Rhythmbox doesn't care
> if I hibernate while playing, but Brasero would trash my CD-R. And
> Transmission would like to be made aware of hibernation so that it can
> close connexions with the server before that.
> 
> Would an extension of the current design make sense? I'm thinking of
> news functions that the apps could use according to their needs, like:
> absolutely inhibit suspend/hibernate; please just tell me before the
> system hibernate, and trigger a callback function; merely inhibit
> automatic sleep. This would be more flexible and more suited to what a
> desktop really needs. What do you think? I can have a look at the code
> if it's worth... Or maybe this should go in DeviceKit-Power?

IMHO, gnome-power-manager should never inhibit a manually-initiated
state transition of any kind.  When I close the lid of my laptop and
chuck it into my backpack, I expect it to suspend, and if an app does
not like that it can sod off -- doesn't matter what it is doing or how
important it thinks that task is.

> Cheers
> 
> _______________________________________________
> gnome-power-manager-list mailing list
> gnome-power-manager-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019