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.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
