KIdleTime: early and/or failing/rejected timeout detection?

[René J. V. Bertin]

Actually, there is one thing I may have missed in the documentation, if it's 
there:

Is KIdleTime supposed to detect system idling, or application idling? As it 
happens, it should be possible to make a distinction between the two with the 
latest implementation I made.

As to using an agent to centralise all polling: I think that agent would either 
have to use poll timer with a sufficiently short interval to serve all clients, 
or use a poll timer per current client. Evidently the latter option cancels any 
benefit of moving to an agent-based architecture (leaving only the IPC 
overhead), while the former will lead to worse overhead than what my current 
implementation allows.
That current implementation is not expensive in its default configuration (and 
that configuration is currently decided at build time), but I think that good 
programming practice would call anyway for deactivating any KIdleTime instances 
when they are not in use, regardless of whether they're based on alarms or on 
polling.

I have no idea how many applications will be using this framework concurrently 
at any given time, but it seems reasonable to expect that there will be less 
than on a system running a KF5 plasma desktop. I see it's used in Baloo, for 
instance, but that framework has dropped support for OS X. 

There's also always the possibility to reconsider implementing an Xcb-style 
alarm based mechanism that relies on a helper process, if it turns out in the 
future that KIdleTime/Mac is causing significant amounts of overhead. But 
KIdleTime has changed only minimally from KDE4 to KF5, and it is certainly not 
the case that it has led to any observable amount of continuous overhead until 
now.

R