expanding the inhibit spec

[Michal Suchanek]

On 21 January 2014 08:09, Bastien Nocera <hadess at hadess.net> wrote:
> On Sat, 2014-01-18 at 12:23 +0100, Michal Suchanek wrote:
>> 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
>
> 1, 2, 4, 3?

These re just random things that you can do. Out of these sleep and
shutdown are clearly related because they happen in hardware. Screen
lock and user switch may or may not. Same for logoff/user switch and
the others.

For example you might want to save your work on user switch if you
have a screen/session lock that prevents the other users accessing
your session later but if your system does not have locking you might
want the system not bother you with that to make the switching faster.

>
> Also, we don't inhibit screen blank/screen lock. We inhibit idle.
>
>> Since the application simulates the user is active
>
> No it doesn't. This isn't the 90's.

Well, it does not use actual input events. However, the end result is
that the idle service which watches for user input to determine
non-idleness receives another kind of event from the application that
indicates that the user is not considered idle. As pointed out
inhibiting idleness indefinitely is not the way to go.

>
> Please reply to the thread in the future instead of writing a new
> e-mail.

Sorry, the downloadable archives are in unintelligible format and the
archive web interface does not support reply.

There is no practical way to reply to an email that did not arrive in my inbox.

Thanks

Michal