Sounds good, but we need some concrete (plausible) use cases. I think we should add them to the wiki [http://live.gnome.org/GnomePowerManager] so other people can comment/add.

What I suggested would probably require a thread instead of a child main loop.

I suppose the registration process can be handled just like how we handle idle inhibitors.  Now we need to detail the protocol for the shutdown notification.

What about having g-s "subscribe" to the suspend handler so that the screen can be locked before we do the suspend (if set for lock on screensaver)? The method would return once the screen has been locked. In that way, the hardcoded list of programs to notify can gradually be removed. Jon, would that be acceptable for g-s?

As an interface, what about:

org.gnome.PowerManager.RegisterPre (string application-name)
 (for actions that happen before the suspend)
and
org.gnome.PowerManager.RegisterPost (string application-name)
 (for actions that happen after the suspend)
with
org.gnome.PowerManager.RegisterCancel (string application-name)
 (so that applications can cancel the registering)

So when we want to suspend, the pre-callback methods are run on each application, we suspend, we resume, then the post-callback methods are run on each application.

If the method block while the application is doing its thing, then we don't have to notify g-p-m when it is done, the method just returns. This is a bit different to the idle inhibitors for g-s, right?

Good idea / bad idea?

Richard

I really think this needs to be done in serial so

 1) applications need to give a priority, just use a number between
    0 and 100. Specifiy in the g-p-m what priorities mean, e.g. it
    may suffice with just

    0-50: normal apps
    90-100: applications that might shut down resources needed
            for other apps. Resources such as networking, so
            e.g. my word processor saves to a network share
            before nm-applet tears down the network

 2) applications need to tell g-p-m (a signal) when they are
    done so g-p-m can move to the next item in the queue

For example it should look like this

 (g-p-m registers with priority 10)
 (nm-applet registers with priority 99)

 a. g-p-m decides to suspend (why in this case is not important)
 b. g-p-m pokes gedit
 c. gedit quick-saves my doc at a remote networking share
 d. gedit tells g-p-m that it's done
 e. g-p-m pokes nm-applet
 f. nm-applet brings down networking
 g. nm-applet tells g-p-m that it's done
 h. g-p-m finally suspends my system

Does that makes sense?

Ugh, I meant

  (gedit registers with priority 10)

instead of

  (g-p-m registers with priority 10)

Sorry.

Btw, this is not about allowing applications to veto stuff; maybe I used the wrong word cuz english is my second language. 

It's about allowing applications to perform actions and release resources in an orderly fashion before an important thing as a suspend takes places.

In fact, I'd argue that g-p-m should enforce timeouts for each application, if it doesn't do it stuff within, say, 5 seconds then it's just tough and we move on to the next. Hmm.. but 5 seconds may be too little for e.g. gedit to complete save a file to a networking share, hehehe.. Something to think about.

Hi David.  That's what I was thinking too.  I'm wondering if instead of waiting for a signal from the remote app why can't we just block in a thread until the method returns.  In the main thread we make sure that this doesn't take more than N seconds.

Does the user care what specifically the application is doing or does she just care that we are "Shutting down Text Editor..."?  Dunno.

Surely blocking (like Jon suggests) might be a better solution than waiting for a second dbus call? Plus I'm not sure about the permissions thing, what just about a bool before-networking, and after-networking?

The thing is that the way g-p-m should notify the app is through g-p-m emitting a signal and you can't block on this. When the app is done, just let the app invoke a method saying so. I don't think this is a particulary complicated state machine you have to manage in g-p-m.

Oh, and I don't think we need g-p-m to show any UI like "waiting for gedit to do XYZ" (and how would g-p-m know what an app is doing and why it wants to post-pone suspend?). 

Oh you also want to track when an app that has registered exists - this is easy to do; just track from the bus when the connection disappears (look at Lock() code in HAL for an example of this). Without this g-p-m might be asking a now segfaulted gedit instance to save documents and this will of course time out.

It could block or perform an async callback if the remote app registered a suspend handler DBUS method.  The return values could communicate the reason for the delay.  Using a method insures that the remote app gets the "message".  There really isn't any way to make sure an app gets a signal that I know of.  If this isn't so important and the timing isn't that important we probably don't need to call a method.

So yeah, using signals is much less complex.

Right, I used the Lock() approach for the gnome-screensaver inhibitor registration.  :)

> Using a method insures that the remote app gets the "message". 
> There really isn't any way to make sure an app gets a signal that I know of. 
> If this isn't so important and the timing isn't that important we probably
> don't need to call a method.

Well, we do know when apps drow of the bus as the bus emits a signal. If the
app fails to respond to the signal it's simply a bug in the app and we fix the
app...

g-p-m will timeout in this case and should probably log somewhere that
the app didn't respond (maybe putting up a dialog, maybe not). Syslog
should be enough...

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

From bug 329265

What we also should take into account in the suspend action interface is programs prohibiting gpm to do a suspend on inactivity. E.g. when Totem is playing a movie we don't want to go into sleep mode

(In reply to comment #15)
> What we also should take into account in the suspend action interface is
> programs prohibiting gpm to do a suspend on inactivity. E.g. when Totem is
> playing a movie we don't want to go into sleep mode

Shouldn't need to do that since they should inihibit the system going idle using the screensaver API.

(In reply to comment #16)
> (In reply to comment #15)
> > What we also should take into account in the suspend action interface is
> > programs prohibiting gpm to do a suspend on inactivity. E.g. when Totem is
> > playing a movie we don't want to go into sleep mode
> 
> Shouldn't need to do that since they should inihibit the system going idle
> using the screensaver API.
> 
This is indeed a very convincing argument to have only one idle calculation routine for a system. :-)

Okay, so we've sorted the inhibit screensaver, and the inhibit suspend on resume cases, now I guess we should provide the interface for pre/post suspend actions.
Is the n-m maintainer in agreement with what we are saying? What else would use the interactive method interface? Would programs like gedit use this interface?

Hm. What do we do about this bug? It's NEEDINFO for quite some time now. Could we maybe close it as OBSOLETE?

Closing as per comment #19.