On Tue, 2014-01-07 at 13:16 -0500, Ryan Lortie wrote: > (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).
It seems to me that what is odd about that API is that it conflates two different types of inhibition, one is application lifecycle and the other system lifecycle. I don't think it makes sense at a system level to merge those two together because they're handled very differently in different parts of the stack. For example on Unity/Mir we're managing the application lifecycle using the Mir connection. This way we can suspend apps based on their position in the window management stack and usage as well as session based things like logging out. For applications being put into a deep sleep and the session being closed are virtually identical. For information on the app lifecycle: http://samohtv.wordpress.com/2013/08/15/application-lifecycle-model-policies/ On the side of system policy like controlling the screen blanking and other power saving mechanisms (for instance you're watching a movie) we have a system service powerd. It runs on the system bus as switching sessions can also have an effect on how it determines how to operate. http://www.mattfischer.com/blog/?p=460 I think that the two types of APIs are sufficiently different that co-mingling them isn't really a gain. Ted
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
