expanding the inhibit spec

[Bastien Nocera]

On Wed, 2014-01-22 at 10:10 +0100, Michal Suchanek wrote:
> 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.

That's 4 things in your list of 3.

>  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.

Why is inhibiting idleness not the way to go? I can't see anywhere in
this mail that it's not the way to go. It's how we've implemented things
right now, and it work pretty well...

> > 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.

The downloadable archives are in mbox format, which your mail
application should be able to import.

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

This is your e-mail:
http://thread.gmane.org/gmane.comp.freedesktop.xdg/13800/focus=13807

You can answer it there or using the NNTP interface.

Cheers