Hello, there is some problem with the archives so I can't read the whole thread about this.
>From the existing API I can see three things that are inhibited - screen blank/lock - system sleep (STR/hibernation) - system shutdown - logoff/user switch and two ways to inhibit - timeout - the operation is inhibited for certain amount of time - permanent - the operation is inhibited until re-enabled There generally exist three reasons to inhibit some action 1) an application is presenting information to the user without requiring user interaction - such as a media player playing a movie, a picture viewer showing a slideshow, etc. In this case the application should assume the user is present and prevent that anything that would happen as result of user idleness. If the application is not scheduled, is locked up, stopped, or anything like that then it is not presenting any information and hence has no reason to inhibit anything anymore. Since the application simulates the user is active it only requires a timeout as when activity ceases the powersaving and security features should resume. The natural way is for the application to ask the session manager to reset the idle timer as it would reset when the user presses a key, moves a mouse, touches the screen, etc. Ideally, the session manager would be able to return the amount of time in which some powersaving feature which inhibits the user from using the application fully would kick in. When passing the message through multiple intermediaries it might not always be possible to determine the timeout so a save default would be something like 10s given that some very aggressive powersaving features dim the display in 30s on some devices. Also, the application would ideally reset the timer when it's showing new content (eg. media player playing) and not when this is not the case (eg. media player stopped). Also media player playing audio only should request that the system should not sleep or power off due to powersaving but should not prevent screen dimming or system shutdown. Also the application should not be required to explicitly name whet it prevents when it merely simulates that the user is present. 2) an application is performing an operation that should not be interrupted (eg. burning CD, installing package, ...) In this case the application should inhibit changing system state permanently until the operation is finished. 3) an application requires user action before system changes state (eg. text editor that requires that file is either saved or discarded before system is shut down). As has been pointed out enabling this can change behaviour expected by the user - powering off the system should power off but now an application can demand that the user decides what the application does before system shuts down. This is definitely something that should be mentioned in release notes but no behaviour satisfies everyone. So long as it can be configured (turned on/off/maybe with a timeout) it should be fine. Note that 2) and 3) can be lumped together or handled differently. 2) presumably does not need user input under normal circumstances but 3) does require user input. The session manager should show some information when attempting system state change inhibited by an application which specifies what applications, and preferably for what reason prevented the state change and should allow inspecting the application in question or terminating it - possibly just by canceling the state change and returning to the session or psesenting its own UI. It should also allow just forcing the state change anyway. Note also the difference between 1) and 2) 3). In 1) no user input is received nor expected and the application wants to continue unimpeded in spite of this. In 2) and 3) user input is received - such as pressing the power button - and application interferes with the action normally carried out when such input is received. I am basically interested in 1) because I don't use features 2) and 3) myself but I can understand they may be wanted in a desktop environment and some users may learn to rely on them. Thanks Michal _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
