<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 7, 2014 at 1:50 PM, Ryan Lortie <span dir="ltr"><<a href="mailto:desrt@desrt.ca" target="_blank">desrt@desrt.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hi,<br>
<br>
Thanks for the reply.<br>
<div class="im"><br>
On Tue, Jan 7, 2014, at 13:42, Simon McVittie wrote:<br>
> Delaying suspend is necessary if you want the screen to lock reliably,<br>
> to avoid this bug:<br>
<br>
</div>I agree that delaying suspend as useful (as I mentioned before).<br>
<br>
It seems like the screensaver situation could be handled more gracefully<br>
as a special-case, though... although my use of "gracefully" and<br>
"special case" together there is already setting off alarm bells in my<br>
own head...<br>
<div class="im"><br>
> Delaying logout/shutdown seems like the only way to get "save changes?"<br>
> prompts to work? Or do you think "authoring" applications (e.g. word<br>
> processor, image editor) should write out current unsaved state to some<br>
> sort of cache periodically or on SIGTERM, and restore it next time<br>
> they're run, like Firefox does?<br>
><br>
> (A word processor etc. blindly doing a normal "Save" when killed with<br>
> TERM doesn't seem good - if the user had intended to "Save As..." a<br>
> different filename, you've just overwritten the wrong file.)<br>
<br>
</div>It's my opinion that in this case you should not use "delay logout" but<br>
rather "block logout", with the understanding that a blocked logout will<br>
always involve user interaction in the case that a logout is attempted.<br></blockquote><div><br></div><div>I've seen users click "Shut Down" and then close the lid or turn the monitor off. Delay is exactly what we want here. An app shouldn't permanently inhibit Shut Down. Yes, the user may lose some data, but staying open forever wouldn't help here, you'd just run out of battery and crash.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In your mentioned case of a word processor I expect that the word<br>
processor would have to keep track of if it has any unsaved changes.  At<br>
the state transition (between unsaved changes and not) it would have to<br>
contact the session to explicitly register the inhibit.<br>
<br>
The one thing I absolutely want to avoid is applications that tell the<br>
session "I may want to pop a dialog at logout; ask me about it then..."<br>
The application should explicitly inform the session about if a dialog<br>
is necessary or not.  If it is necessary, the dialog _will_ be popped up<br>
(probably by the session, as is the case for gnome-shell).  If it is<br>
not, then the session _will_ logout, and the only courtesy that an<br>
application will receive is a SIGTERM signal followed by a short grace<br>
period before it sees SIGKILL.<br>
<br>
<br>
Perhaps what is really needed is a block-only (no delay) inhibit API<br>
alongside a separate "inform of suspend/hibernate with allowances for<br>
short delays" API.<br>
<br>
Cheers<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
xdg mailing list<br>
<a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>