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