[KDE/Mac] Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[Dario Freddi]

Hi René,

just thought I'd clarify some things as the creator/former maintainer of
all this - which might also justify some of Martin's positions.

The idea behind KIdleTime is that the framework shall be a lightweight,
non-critical framework for those applications which want to know about the
idle time of the system. The only critical application relying on KIdleTime
is (as expected) the power manager (which was also where the framework came
from, if you remember). As such, we work under the following assumption:

 * We don't want/need to report the idle time precisely. We care about
timeouts and an error in the order of seconds is acceptable (here comes
Martin's argument). The reason why the API returns the idle time in msec is
just a matter of consistency with Qt's API, which always return msec as the
base unit for time.
 * If an application is relying on having a msec-accurate idle time, I have
very bad news for its developer :) It's just impossible to provide
warranties that we can be that accurate on all platforms.
 * KIdleTime strives to be as lightweight as possible. This is something
which came from the old approach used in KDE3/4 powermanagement which was
basically stressing the system just to find out how long it has been idle
(the irony)


I agree with you about the lack of documentation, and it'd be great if
something put that in a better shape. We're fine to assume that KIdleTime
will be initialised with no functional backend, because we assume that if
we can't determine if the system is idle, we assume it is always active. It
is indeed not documented, and I agree with you on that, but the approach
definitely makes sense given the assumption above. It is, on the other
hand, responsibility of applications which use the idle time as a critical
resource (aka: the power manager) to take care of this, but it was deemed
crazy to bring in such complexity for those applications which might care
only about doing stuff in a more conservative way when the system is not
idle.

Also, this applies to strange setups (remote login): it is tied to a series
of limitations and, especially in the case you mentioned, the concept of an
"idle system" is definitely ambiguous, as you are dealing with... two
different systems. And if we can't give warranties about computing, we
simply don't.

That said, I really appreciate you improving the OSX backend. Thanks!


I hope to have shed some light on this.

Best



2015-11-19 14:38 GMT+01:00 René J.V. <rjvbertin at gmail.com>:

> There's something else that's been bothering me since I realised it:
> KIdleTime has been written with the assumption that'll always work, and
> that whatever initialisation is required never fails. That must be why the
> return value from setupPoller() is discarded.
>
> Maybe this all holds true on Linux, where initialisation probably only
> fails if there's no valid connection to an X server or a severe
> out-of-memory condition. The former will lead to sufficient explicative
> feedback to the user, the latter, well, it'd still be nice to simply print
> a message and then exit without triggering crash reporting stuff that's
> only going to increase the system load.
>
> On OS X, there is a very valid situation in which initialisation could (or
> should) fail and that cannot be predicted from something like the absence
> of an env. variable like DISPLAY : remote login. That's a more generic
> problem that affects Qt applications in general, though.
>
> Anyway, I don't see anything in the documentation that suggests that
> applications can verify whether any of the KIdleTime features are going to
> work (= are implemented). Idle time is reported as 0 when there is no
> platform plugin (which is a valid time, not an error value), or whatever
> the platform plugin returns if it cannot determine a sensible value. The
> other, signalling features probably just fail to deliver signals if they
> are not supported. I haven't seen a warning for that in the documentation,
> so that could lead to 2 things:
>
> - either dependent software just never gets to do the (possibly important)
> things it is designed to do when an idle period ends or reaches a given
> duration.
> - or developers deduce that they have to write additional checks, possibly
> through polling to detect and handle situation in which KIdleTime fails to
> do its job ... but then why would they even use KIdleTime at all?
>
> R.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20151119/80d41914/attachment.html>