Re: gnome power manager inhibit

["Scott J. Harmon" <harmon ksu edu>]

Alex Jones wrote:
> I'd say there are three situations, not just "auto" and "manual":
> 
>    1. when it decides for itself if it wants to suspend (idle);
>    2. when the user asks it to suspend (clicks "suspend"); and
>    3. when the user forces it to suspend (closes lid). 
>
> 
> If any applications are inhibiting suspend in case 2, a dialogue should
> pop up and some protocol should allow the applications inhibiting to Do
> The Right Thing™ before suspension. Maybe we already do this?
> 
> But in case 3, this is unacceptable for the reasons you said -- the user
> confirmation should either be skipped over, or have a timeout on it.
>

I was thinking a timeout would be the thing to do in both situation 2
and 3 (similar to the shutdown timeout, btw the inhibit suspend hint
would probably also be useful for shutdown...i.e. you are currently
updating your system, cancel?).  Then we can go back to two situations
only ;-)

> On Fri, 2007-10-19 at 20:01 -0500, Scott J. Harmon wrote:
>> Benjamin Gramlich wrote:
>> > Isn't this discussion a bit moot since gnome has a "suspend inhibit"
>> > applet that you can turn on in situations when you want to sit back
>> > and watch a movie or download a .iso image?
>> >
>> No.  But I do have to say, I would rather the laptop suspend and kill my
>> download or file move than have it catch fire in my backpack (i.e. I
>> closed the lid while it was doing something inhibiting the suspend). 
>> Surely auto-suspend operates differently than when *I* tell the machine
>> to suspend (i.e. closing the lid, or clicking suspend).
>>
>> This whole conversation, I assumed, is about _auto_suspend, not manual
>> suspend, right?
>> >
>> >
>> > On 10/19/07, *Richard Hughes* <hughsient gmail com <mailto:hughsient gmail com>
>> > <mailto:hughsient gmail com>> wrote:
>> >
>> >     On Fri, 2007-10-19 at 18:52 +0100, Odysseus Flappington wrote:
>> >     > It appears to me that how Gnome Power Manager determines whether the
>> >     > computer idle before it suspends/hibernates could be better
>> >     designed.
>> >     > I understand that it is each application's responsibility to inhibit
>> >     > the computer from sleeping while in use
>> >     > ( https://wiki.ubuntu.com/GnomePowerManagerInactiveSleep
>> >     <https://wiki.ubuntu.com/GnomePowerManagerInactiveSleep> ), however
>> >     > there are so few Gnome apps that actually implement this
>> >     properly that
>> >     > I'm beginning to believe there must be a better way of doing this.
>> >
>> >     Well, we've discussed quite a few ways of doing this in the past -
>> >     kpowersave just checks a blacklist of processes which is completely
>> >     wrong way to do it in my opinion. Having a nice interface lets us do
>> >     clever things.
>> >
>> >     > Just a few example of Gnome putting the computer to sleep while
>> >     doing
>> >     > stuff, these are off the top of my head and go alongside countless
>> >     > others that I've come across:
>> >     > - Firefox when playing Flash.
>> >
>> >     Surely you want that to suspend if there's been no movement for 15
>> >     minutes? flash kills the battery life..
>> >
>> >     > - VLC when playing music.
>> >
>> >     Rhythmbox already inhibits gnome-power-manager.
>> >
>> >     > - Kino while capturing video through firewire.
>> >
>> >     Sure, it should do, although it's not dbusified IIRC.
>> >
>> >     > - Synaptic Package Manager while downloading packages!
>> >
>> >     PackageKit already does this :-) - I think the ubuntu update
>> >     applet also
>> >     does an inhibit.
>> >
>> >     > - While copying files in Nautilus!
>> >
>> >     A bug was files many months ago about that - Nautilus needed to
>> >     pick up
>> >     a dbus dep which the maintainers at the time didn't like. I think
>> >     we can
>> >     revisit that one now.
>> >
>> >     > This is pretty basic laptop stuff, and since equivalent bugs
>> >     haven't
>> >     > been reported on Windows and that generally I've never come across
>> >     > these problems, I would conclude that they've found a more effective
>> >     > way of implementing this.
>> >
>> >     They haven't. Asking each app "can i suspend?" doesn't scale, and it
>> >     only takes one app to say "no" all the time to get a very hot closed
>> >     laptop.
>> >
>> >     > Are there any plans to look at the design of the suspend/hibernate
>> >     > mechanisms that Gnome implements and re-work them? What
>> >     consensus has
>> >     > been reached regarding this issue already?
>> >
>> >     Well, over time more and more stuff uses these interfaces. I think
>> >     brassereo (sp?) already uses the interface when burning a CD. It's
>> >     probably a 10 line patch to add this functionality into applications.
>> >
>> >     Richard.
>> >
>> >
>> >     _______________________________________________
>> >     desktop-devel-list mailing list
>> >     desktop-devel-list gnome org <mailto:desktop-devel-list gnome org> <mailto:desktop-devel-list gnome org>
>> >     http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > desktop-devel-list mailing list
>> > desktop-devel-list gnome org <mailto:desktop-devel-list gnome org>
>> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>> Scott.
>>
>> -- 
>> "Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
>>
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list gnome org <mailto:desktop-devel-list gnome org>
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Scott
-- 
"Computer Science is no more about computers than astronomy is about
telescopes." - Edsger Dijkstra