Version: (using KDE KDE 3.5.6) Installed from: Ubuntu Packages Quite a few KDE applications, e.g. Kate, can ask for user actions if there are unsaved documents open at shutdown. This is probably all fine and dainty, but it forces the user to babysit the shutdown sequence, and prevent the e.g. following usecase 1. Turn off monitor (won't be using the computer for a while) 2. Come back, decide it's time to shutdown, press the "shutdown now, no confirm dialog." (Default: alt-ctrl-shft-pgdn) 3. Computer shuts down nicely, doing whatever it wants with unsaved documents. In practice, 3 will hang the computer till next time I come around, usually next morning or afternoon. Given the power consumption of computers these days, that is somewhat annoying. So I suggest a solution... like a (configurable?) timeout of say 1 hour or so. If neither the user nor the application can finish the shutdown sequence in an hour, they are probably not going to. I know I am not alone in this... quite a few of my colleagues are complaining about this issue as well :)
i second that, but it is not mine. :) does xsmp support such a thing?
Quoting from http://www.xfree86.org/current/xsmp.pdf -<-- snip -<-- Interact [Client ← SM] Valid Responses: InteractDone This message grants the client the privilege of interacting with the user. When the client is done interacting with the user it must send an InteractDone message to the SM unless a shutdown cancel is received. Advice to Implementors If a client receives a ShutdownCancelled after receiving an Interact message, but before sending a InteractDone, the client should abort the interaction and send a SaveYourselfDone. -<-- snip -<-- It would seem that this scenario was not included. The state chart says the same. Still, if kdelibs could provide an appropriate timing-out dialog for applications to use, we could at least solve this for any KDE applications out there.
I don't quite see the need for a timeout, but XSMP has support for this, (not) allowing any user interaction (e.g. QSessionManager::allowsInteraction). However I'm afraid the support for this in KDE is as poor as support for other aspects of session management.
the timeout would be there to avoid having to define two separate key sequences for "shutdown without initial dialog, but with possible feedback" and "shutdown unconditionally". fwiw, i think a timeout of 10 minutes is already excessive - if you don't notice within that time frame that something is wrong, you most probably won't notice it later, either.
This has now been implemented. When an app is is blocking logout, you're shown a notification telling you about it, and you have 2 minutes to decide what to do (cancel log out to handle it, or log out immediately). If you don't, the system logs out anyway and the app gets unceremoniously killed.