idle detection

[Luke Schierer]

On Thu, Aug 02, 2007 at 12:43:02AM -0700, Sean Egan wrote:
> On 8/1/07, Richard Laager <rlaager at wiktel.com> wrote:
> > Unless you've changed the code or there's a bug (such as the hardcoded
> > IDLEMARK vs. the pref), we poll at the point where the logic will
> > register a change. For example, if you're supposed to go away after
> > being idle for 10 minutes and you've been idle for 2 minutes, we'll
> > check again in 8 minutes.
> 
> Right, I should have been clearer. In any case, I think we agree that
> the going-to-idle case could not be made more efficient.
> 
> > I don't see why you need to have this detected instantly.
> 
> Sure. What was I thinking?
> 
<snip> 
> I'm teasing, obviously, but there should be no latency between when a
> user's state changes and when we report that change. If I were ever to
> experience a one minute latency in anything that was supposed to
> detect my use of the keyboard and mouse, I would without doubt
> consider that a major bug.

This comment represents both my own use and that of a significant number
of comments I have seen also.  Users are very quick to think that
something is broken when the change to or from idle (or away) is not as
fast as they expect.  Recall that we periodically get questions along
these lines stemming from the timeout for typing as you set a one-off
status message. 

The responce time needs to be short, exactly how short is more debatable
(without testing), because just how quickly someone will notice that
their own status has not changed will vary significantly across the user
base.

One thought I had though that might work would be to have the longer
polling period, but force idle off if the conditions for Pidgin use idle
are met.  Then if any message is sent, or the status changed, or
similar, we'll come back from idle immediately.

luke