expanding the inhibit spec

[Ryan Lortie]

hi,

Thanks for the reply.

On Tue, Jan 7, 2014, at 13:42, Simon McVittie wrote:
> Delaying suspend is necessary if you want the screen to lock reliably,
> to avoid this bug:

I agree that delaying suspend as useful (as I mentioned before).

It seems like the screensaver situation could be handled more gracefully
as a special-case, though... although my use of "gracefully" and
"special case" together there is already setting off alarm bells in my
own head...

> Delaying logout/shutdown seems like the only way to get "save changes?"
> prompts to work? Or do you think "authoring" applications (e.g. word
> processor, image editor) should write out current unsaved state to some
> sort of cache periodically or on SIGTERM, and restore it next time
> they're run, like Firefox does?
> 
> (A word processor etc. blindly doing a normal "Save" when killed with
> TERM doesn't seem good - if the user had intended to "Save As..." a
> different filename, you've just overwritten the wrong file.)

It's my opinion that in this case you should not use "delay logout" but
rather "block logout", with the understanding that a blocked logout will
always involve user interaction in the case that a logout is attempted.

In your mentioned case of a word processor I expect that the word
processor would have to keep track of if it has any unsaved changes.  At
the state transition (between unsaved changes and not) it would have to
contact the session to explicitly register the inhibit.

The one thing I absolutely want to avoid is applications that tell the
session "I may want to pop a dialog at logout; ask me about it then..." 
The application should explicitly inform the session about if a dialog
is necessary or not.  If it is necessary, the dialog _will_ be popped up
(probably by the session, as is the case for gnome-shell).  If it is
not, then the session _will_ logout, and the only courtesy that an
application will receive is a SIGTERM signal followed by a short grace
period before it sees SIGKILL.


Perhaps what is really needed is a block-only (no delay) inhibit API
alongside a separate "inform of suspend/hibernate with allowances for
short delays" API.

Cheers