Michal Suchanek
2014-01-18 11:23:32 UTC
Hello,
there is some problem with the archives so I can't read the whole
thread about this.
- 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
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