Richard, shouldn't inhibiting only stop the idle actions (on inactivity) and not the explicit (button or widget initiated) ones?

Well I figured both - imagine the scenario of a software update calling Inhibit() and you really don't want to suspend during a rpm transaction, even if you have pressed the button.

Maybe we need a better inhibit call, i.e. Inhibit and ReallyInhibit?

I guess basically my thoughts haven't changed since
http://bugzilla.gnome.org/show_bug.cgi?id=334809#c4
http://bugzilla.gnome.org/show_bug.cgi?id=334809#c6

Basically, if I click suspend or close my laptop it is because I really mean it.  If I am listening to music then it should stop where it is and resume later.  If I am updating software then it should stop and resume later.  etc.  Anything that doesn't do that we should fix.  Maybe we'll lose a CD but so what - that's my fault.

If g-p-m doesn't suspend when I want it to then that is bad - as this bug suggests.

As far as method names, just make them long, no harm in that. 

InhibitAutoSuspend()
InhibitAllSuspend()

or something.

I'd like to bring to your attention the following bug I filed:
http://bugzilla.gnome.org/show_bug.cgi?id=384545

I expect the solution may well be applicable to that also.

I've been thinking of it in terms of 'hard' or 'soft' inhibit.  This distinction might be one of those things that only makes sense if you already understand it, though.

2007-02-01  Richard Hughes  <richard@hughsie.com>

	* data/gpm-inhibit-test.glade:
	* docs/dbus-interface.html:
	* docs/dbus-interface.xml:
	* docs/icon-scheme.html:
	* docs/index.html:
	* src/dbus/gpm-dbus-inhibit.xml:
	* src/gpm-inhibit-test.c: (dbus_inhibit_gpm),
	* src/gpm-inhibit.c: (gpm_inhibit_find_cookie),
	* src/gpm-inhibit.h:
	* src/gpm-manager.c: (gpm_manager_is_inhibit_valid),
	* src/gpm-powermanager.c: (gpm_powermanager_inhibit_auto),
	* src/gpm-powermanager.h:
	* src/gpm-self-test.c: (test_inhibit):
	Convert the new API to InhibitAuto for auto-suspend prevention and
	InhibitManual for stuff like RPM transactions and BIOS flashes.
	The old manager inhibit API has been converted to the InihibitAuto
	style to fix #402863
	Update the self test program, the inhibit example program and the
	documentation.

This means if you use g-p-m svn then rhythmbox does the right thing.

We've done some real hard work in the kernel to get alsa and drivers to properly suspend/resume the stream so whatever application was using the card can function properly over suspend.

Maybe I just want to suspend and resume playing afterwards? I don't think rhythmbox should make *any* policy decisions.

*** Bug 547418 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> 2007-02-01  Richard Hughes  <richard@hughsie.com>
[snip]
> This means if you use g-p-m svn then rhythmbox does the right thing.

I guess this requires some change in rhythmbox, because it's over a year later and rhythmbox still prevents explicit (non-auto) hibernation.

Increasing severity to critical because this can lead to data loss, for instance when Rhythmbox prevents hibernation due to low-battery (automatically, or when closing a laptop lid because you know that the battery is low).

(In reply to comment #10)
> I guess this requires some change in rhythmbox, because it's over a year later
> and rhythmbox still prevents explicit (non-auto) hibernation.

Not as far as I can tell.  It appears that g-p-m dropped the distinction between inhibiting automatic and manual actions; I'm not sure what semantics the Inhibit request is supposed to have now, but that's all there is.

*** Bug 552969 has been marked as a duplicate of this bug. ***

bug 552960 describes something a bit trickier. There are "voluntary" vs "automatic" suspend scenarios, but inside the voluntary one, there are two subscenarios: hotkey/menu request vs lid close. Copy-pasting:

Rhythmbox should only inhibit "timed" suspend/hibernate actions, not "manual"
actions such as pressing the "suspend" button on a keyboard. 

It SHOULD make an "exception" however, when closing the lid of a laptop, as this
might be a special case (ie: I want to put the laptop in a bag while still
listening to music). However, when I press the suspend hotkey (or access it
through gnome's menus), I really "mean" suspend.

So, to summarize:
- when the user starts the action manually:
-- if lid closes: inhibit
-- if not a lid event: do not inhibit
- when the computer requests automatically (idle): inhibit

*** Bug 579908 has been marked as a duplicate of this bug. ***

I am a new Rhythmbox user, changed from Banshee.

I prefer Rhythmbox on all aspects, except that it won't me let hibernate when the music is playing. This is really annoying. 

Right now my Pulseaudio (0.9.10) has a problem with hibernate, sometimes I have to restart the apps playing music, but I prefer that to let Rhythmbox decide for me when can I or cannot suspend! I disabled the plugin after unhiding it in gconf-editor, but I don't understand you have you hidden it?

I don't understand the arguments in comment #14 (Jean-François Fortin Tam). I would say that the usual intention when closing the lid is to perform whichever action was configured in the power management settings. If you *do* want to inhibit suspend in that case, because you want to play music in your bag (?!) I'd say you should use the inhibit panel applet (that exists, right?) because you're most likely a minority and everyone else will suffer overheated laptops if Rhythmbox inhibits suspend for lid-close events, whereas you'll just suffer having to press a few buttons if it doesn't.

Explaining the "lid close" part of comment #14: I use my laptop as a portable music player (with headphones). I put it in my messenger bag when walking or using the public transit. It blanks the screen and saves energy (and space). This worked well with older not-power-efficient laptops (with pentium M CPUs, for example), and it works even better now that I have a passively cooled netbook (Mini 9) which produces little heat.

I would REALLY REALLY hate losing this feature. If I wanted the thing to actually suspend when putting it in my bag/closing the lid, I would either:
- have stopped the music (is it that hard? ;)
- disabled the rhythmbox power management plugin (if I didn't want rhythmbox to interfere at all)
- pressed the actual power button instead of closing the lid (not implemented; this is what this bug is about, "soft" vs "hard" inhibit)

I don't think that's a bug either.  Many many people want to close the lids of their laptops when music plays so that they can listen to music while saving power or transporting the laptop from one place to another (think "car" scenario).  I have personally witnessed that.

I think it is a very reasonable default to inhibit suspend as long as music is playing, that this inhibition be removed when the last song plays, and that this should be presented to the user as a menu option, defaulting to ON, titled "Play music even with the lid closed" or "Do not suspend machine while music is playing" -- naturally this option ought only be displayed if the computer has a LID.  Note that the oposite -- i.e. an option defaulting to OFF titled "Stop music when the lid is closed" because that would make the music stop even if the machine is not suspended by policy -- and that does not make sense.

All in all, that's my view.  What we need to do is find out what the expectations of actual Rhythmbox users are, or dictate a policy and have an option for the large minority that doesn't agree with the default one.

If there's going to be a setting like that, it doesn't belong in rhythmbox at all.  It's not an application preference, it's a system preference.

I've changed the gconf defaults so the power manager plugin is not active and not hidden, at least until we can make it behave itself.  The plugin apparently needs to be rewritten to use the gnome-session 2.26 dbus interface some time soon, which might solve some problems.

Why cannot rhyhtmbox turn off Inhibiting, or give an option for it, until it works as it should? Too many times do I close the lid and find my computer warm in the morning, playing music all night (quietly, since it was evening). This is absolutely not good for my computer and gnome-power-manager and rhythmbox are collaborating in the totally wrong way here.. not to save power or computer lifetime but the opposite.

The plugin is disabled by default, as I said in comment 20.

I think I will restate this, as it seems on a re-read I did not make myself terribly clear, and I'm not sure what the plan for the future is:

* Inhibiting on lid-close by default will lead to heat-damaged laptops for those that don't expect it.
* Not inhibiting on lid-close by default will lead to slight inconvenience for those that want it.

I think the rational choice is pretty clear.

Sorry for the fury, thank you for taking the conservative and sane approach as outlined by Jonas.

One useful (for me) improvement in this corner would be to use the power management plugin to Pause Rhythmbox when suspending. Mostly you don't expect rhythmbox to play when unsuspending, and not all sound hardware handles suspending with playing sound very well.

*** This bug has been marked as a duplicate of bug 596573 ***