expanding the inhibit spec

[Lennart Poettering]

On Tue, 07.01.14 13:50, Ryan Lortie (desrt at desrt.ca) wrote:

> 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...

There are a lot more cases like this. For example service discovery
frameworks want to tell other hosts on the network that they re no
longer available so that other UIs can be nicely updated. THink gupnp or
Avahi.

Jabber clients want to change the idle state before suspending, and so
on...

> > 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.

How's that supposed to work? If the shutdown was blocked, its is
entirely denied, so who will then reschedule the shutdown later? The
word processor which wanted to show this dialog?

> 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..." 

Note that our upstream wiki page about shutdown/suspend delay inhibition
actually explicitly explains that the delay locks should only be taken
when the files they edit "are dirty", and that they should be released
as soon as everything is synced to disk. 

I am pretty sure it's a matter of documentation and getting the APIs
right to make people not take these locks too early and unnecessarily.

Lennart

-- 
Lennart Poettering, Red Hat