KIdleTime : to poll not or provide a settable resolution for the polling backends?

[René J. V. Bertin]

Martin Graesslin wrote:

Sorry, long reply, too many arguments.

> Don't poll. Never ever, don't poll. That's the opposite of what an 
application wants to do. 

As I said elsewhere, while I agree on the principle I don't think that should be 
dogma. It depends on the requirements of the application in question, and the 
facilities provided by the operation system on which it's running. There are 
perfectly justifiable use cases in which detection precision and reaction time 
prime over being nice to others (and risk being moved to the end of the event 
processing queue).
The KIdleTime documentation does not make any statements as to whether it is NOT 
to be used for anything with real-time-like requirements. It's the possibility 
to serve that specific kind of use-case that I had in mind (which is for 
application developers to decide on, not KF5 developers...). If there's an 
existing sensible default then that should of course be incorporated in a new 
mechanism to provide a settable polling resolution.

> I think it's better to not provide the feature than to perform polling.

I don't agree in this case. Not with my background in which a reliable and 
precise detection of idle periods and/or user input could have come in very 
handy.
It's simple, really. The KIdleTime documentation should provide information on 
the underlying implementation, and point out that polling might be used. Anyone 
looking into using the feature can then decide for themselves whether or not 
that is an issue -- and control the polling overhead via the new mechanism I'm 
proposing.

> Ah found it. It's in the parent WidgetBasedPoller. I think that implementation
> already answers how you should do the polling, because it has an
> implementation for it. But nevertheless: please try to not poll.

That implementation still polls. It only uses a widget to refrain from polling 
as long as there is user activity, but according to the documentation this is 
true for a QTimer with interval 0 too (in that case the timer fires only when 
there is no activity).

>From what I understand of the code, WidgedBasedPoller still polls at a 
calculated interval when there is no activity, and uses a fixed margin of error 
for determining whether a timeout was reached.
*** That margin is smaller than the one originally used in macpoller.cpp, but 
we're still speaking of an undocumented ±300ms error on the timeout detection.

I don't understand why the `mintime` calculation is repeated at each poll (I 
rolled my own unknowingly, in the methods that add or remove a timeout to the 
list, and I think Qt has a datatype that orders that list so the minimum is 
always the 1st element).

*** What is the idea behind setting the poll timer to `mintime - idle`? Am I 
right that the grabber widget allows to stop the polling as soon as activity 
resumes (removing the need for QTimer::interval==0)?
If so, it still seems suboptimal to use the exact "error" (remaining time to 
wait) as the poll interval. I'm not the best expert on control theory of the 
class, but I do remember it's generally a bad idea to drive a feedback loop with 
the unmodified error. Something like (mintime-idle)/2 should lead to more stable 
behaviour (and the best possible precision during the last <2ms).

BTW: shouldn't the code use QTimer::setInterval in case the timer is already 
running? According to the documentation, QTimer::start(msec) will first stop and 
then restart the timer. If QTimer::setInterval doesn't (not documented...) that 
ought to be preferable, no?

Anyway, I'd adapt my proposition to include the existing implementation as the 
default, which could also be (re)selected by something like 
KIdleTimer::setResolution(KIdleTimer::DefaultResolution) (== -1).

As to MacPoller: I'll see whether I subclass WidgetBasedPoller or whether it's 
just as efficient to copy/paste the relevant code (if I'd be overriding too many 
methods, which might be the case here).

R.