Re: gnome power manager inhibit
- From: "Benjamin Gramlich" <benjamin gramlich gmail com>
- To: "Richard Hughes" <hughsient gmail com>
- Cc: desktop-devel-list gnome org
- Subject: Re: gnome power manager inhibit
- Date: Fri, 19 Oct 2007 19:48:35 -0500
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?
On 10/19/07, Richard Hughes <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
> 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
> 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
> 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.
desktop-devel-list mailing list
desktop-devel-list gnome org
] [Thread Prev