david at fubar.dk
Sat Mar 31 10:01:29 PDT 2007
On Sat, 2007-03-31 at 10:07 +0200, Lubos Lunak wrote:
> I'm still not quite sure Inhibit() even belongs to PM interface, I
> cannot think of a single case when an app would want to block suspend
> but would not want to block logout, so it'd always have to block both
> of them. However the SM semantics (at least as they're in XSMP)
> wouldn't allow blocking PM suspend by blocking SM logout. Not that I
> have any better idea.
There are at least two classes of applications
a. Apps that want to cancel logout; this could be some number-crunching
application that just operates on local files that lives in the
home directory of the user. These apps don't care if the system is
suspended/hibernated, but they do want to cancel logout.
b. Apps that depends on entities/services external to the session; e.g.
networking and devices. This includes 1) disc burning (you get a
coaster if you suspend the box); 2) downloading files (may take
hours so you don't want the box to suspend because the session
becomes idle); 3) probably other examples.
Apps in class b. justify the Inhibit() method; they want to more than
just block logout; their operation depends on external entities that may
disappear if the system e.g. suspends / hibernates.
So I think it's like this:
- Apps in class a. should just use XSMP (or Inhibit() on the proposed
org.fd.SM D-Bus interface); and
- Apps in class b. should use Inhibit() on the org.fd.PM D-Bus
And as you note b. surely implies a. so the
- org.fd.PM spec needs to say that PM daemon implementing this
interface should/must use XSMP to delay and possibly cancel logout
if, and only if, someone is inhibiting the PM actions.
- the docs for Inhibit() needs to specify that the PM daemon will
delay/cancel logout via XSMP on behalf of the caller. This is
important because application authors need to know that they don't
have to do this themselves.
Sounds about right?
> > Specifically, as you mention, existing PM
> > daemons like gnome-power-manager, kpowersave etc. would just provide
> > both "interfaces" until something better comes along to provide
> > org.freedesktop.SessionManagement, e.g. for GNOME it . Notably we can
> > extend this interface later on.
> Yes. A session management providing merely shutdown/reboot/logout is vastly
> insufficient and would basically just use the XSMP-provided functionality
> (plus whatever starts the shutdown/reboot afterwards). I originally suggested
> the org.fd.ShutdownManagement name because of this but if this is meant to be
> extended somewhen in the future than I think it can be called
Maybe we just punt org.fd.SessionManagement and tell apps in class a. to
just use XSMP? I mean, at _some_ point someone will write a spec for
org.fd.SM or similar so apps can migrate from XSMP to something better
and I don't think we should make it harder for them by defining parts of
their interface in advance.
More information about the xdg