expanding the inhibit spec

[Ryan Lortie]

hi,

(with the toolkit maintainer hat on) I want to expand the Inhibit spec:

  http://standards.freedesktop.org/idle-inhibit-spec/0.1/

Specifically, I am interested in supporting this API:

  https://developer.gnome.org/gtk3/stable/GtkApplication.html#GtkApplicationInhibitFlags

with exactly one common D-Bus interface that is implemented by any
freedesktop desktop environment that I may find Gtk applications running
on (ie: anywhere other than macos and win32, which already have their
own backends).

Right now, we use gnome-session.  That's obviously problematic from the
standpoint of Gtk running anywhere other than desktops based on GNOME. 
We have a proposal to add support for attempting first to use the idle
inhibit spec in the case of wanting to inhibit idle, with a fallback
path for other cases or the case that this interface is not available,
but this is precisely the sort of thing I want to avoid.

I just want one interface that I always use.

Some more prior art for this is the logind inhibit interface:

  http://www.freedesktop.org/wiki/Software/systemd/inhibit/

In my opinion, the flavour of this interface is more or less correct but
there's a couple of reasons why I don't think that using the systemd
interface directly is appropriate:

 - not everyone is using logind
 - the logind interface is on the system bus
 - it is labelled as being a "privileged operation"

I'd want an interface that is on the session bus and designed to be used
by normal applications (perhaps subject to sandboxing restrictions).

I also find the use of "delay" inhibits to be slightly distasteful, at
least for logout or shutdown.  In my opinion, applications that want to
do cleanup tasks on exit should register SIGTERM handlers and deal with
them that way, exiting when done.  I understand that it may be useful to
know when the system about to suspend or hibernate, however, in order to
sync up files on disk (just in case) or close network connections.

The service that implements this in the session would surely need to
communicate with other processes in order to coordinate this.  It would
at least have to communicate with the process responsible for the
screensaver to prevent it from being activated and with logind in order
to forward information that it might care about.  I believe that this is
a good argument for having a single "one stop shopping" interface
instead of many finger-grained ones.  It's easier to use on the consumer
side and on the implementation side, no matter what, there is going to
have to be some forwarding of requests.

I'm sure there will be a lot of input on these ideas.  My plan is to
just propose something that looks vaguely like logind's API, but on the
session bus level, and based on application IDs (or desktop file names)
but I will wait until hearing some feedback before proceeding on to more
concrete proposals.

Thanks in advance for the input.