<div dir="ltr">Hi René,<div><br></div><div>just thought I'd clarify some things as the creator/former maintainer of all this - which might also justify some of Martin's positions.</div><div><br></div><div>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:</div><div><br></div><div> * 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.</div><div> * 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.</div><div> * 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)<br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>That said, I really appreciate you improving the OSX backend. Thanks!</div><div><br></div><div><br></div><div>I hope to have shed some light on this.</div><div><br></div><div>Best</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-19 14:38 GMT+01:00 René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
- 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.<br>
- 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?<br>
<span class="HOEnZb"><font color="#888888"><br>
R.<br>
</font></span></blockquote></div><br></div>