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. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg