Re: [gpm] Limiting inhibition by applications

[Milan Bouchet-Valat <nalimilan club fr>]

Hi again!

I'm wondering how you feel about the issue I raised about a month ago. I
received one positive answer, but how do you think this should be fixed?
By a mere return to the previous behavior, or by introducing new calls?
Richard Hughes, any ideas?


Cheers

> On Nov 29, 2008, Victor Lowther wrote:
> 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     
> > http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list
> -- 
> Victor Lowther 
> RHCE# 805008539634727 
> LPIC-2# LPI000140019 
> 
> _______________________________________________ 
> gnome-power-manager-list mailing list 
> gnome-power-manager-list     
> http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list