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

[Martin Gräßlin]

Am 2015-11-18 12:33, schrieb 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.

What's an "idle application"?

> 
> 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.

Let's assume: you have two applications performing polling at a 3 sec 
interval: this means two applications are woken up every three seconds. 
That's already 100 % more wakeups compared to a daemon solution.

The number of applications using the agent doesn't affect the usage at 
all. Why should an agent with two clients at 3 sec interval need more 
timeouts?

At max such an agent approach needs to poll in an interval serving the 
shortest timeout. This means it's as good as this one client. The other 
ones come for free. If I have one with a three second timeout and one 
with a five second interval, I only need to poll for the three second 
interval. Only if that one is hit, the five second interval becomes 
interesting.

> 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.

NO POLLING! Given your reply here, you did not even properly consider my 
argument at all. Which is sad. I'm spending quite some time here to help 
with the OSX implementation. I could also do a "what do I care about 
OSX?" Instead I spent quite some time on it.

Cheers
Martin