Given I already stepped in... 2015-11-19 10:36 GMT+01:00 René J.V. <rjvber...@gmail.com>: > > Now it's just bad code, eh? > > Just for the record: no one but Apple really knows what IOKit considers being > idle but it clearly involves absence of user input events. That's "user > idle", not "system idle" (term from the KIdleTime docs!), and how long of the > former you need to attain the latter (or something you consider "system > idle") is completely up to the software to decide. Because it involves event > timing, this can be determined with as much precision as native events can be > timed (and if I'm not mistaken those are accurate enough to support a 1ms > resolution on OS X). > > I'm not going to repeat my position on polling or on how it's up to the user > to decide whether or not idle timeout detection is too expensive. > As long as people here remain dead-set against anything the uses it without > even testing the actual implementation, then I am not going to reconsider > contributing to this code. Writing great software doesn't necessarily mean > applying all applicable principles without wiggle room (and I'd hope that's > about the only thing I'm dogmatic about myself :)). > > Apparently I might want to reconsider using QTimer, though, there might be > more accurate and/or less intrusive mechanisms available natively - and now > that I incorporated some ObjC it ought to be a lot less work to experiment > with those.
René, Martin was just questioning your choice of Qt::PreciseTimer. From Qt docs: For Qt::CoarseTimer, the interval will be adjusted up to 5% to align the timer with other timers that are expected to fire at or around the same time. The objective is to make most timers wake up at the same time, thereby reducing CPU wakeups and power consumption. Which is *exactly* the purpose of KIdleTime - notifying with a relaxed precision (because let's face it, as Martin already explained the added precision value is completely pointless if we're talking about **user** activity) with the minimum consumption of system resources. And this is exactly what :CoarseTimer does. So I stand behind Martin's comment and agree with it. It does not relate to IOKit or anything else, but just with the purpose for which you're using QTimer in that context. And note that people here are not dead-set without concrete and actual reason: the new Qt5 API of QTimer was designed with these kind of use cases in mind. The fact that (of course) you don't notice any concrete difference might change when you scale back to a more constrained system - and it's the purpose of frameworks to be as efficient as possible everywhere. And most of all, there's no gain in using PreciseTimer at all here - actually KIdleTime might even use VeryCoarse. That's all. In the bigger scheme: would you be happy to know that your laptop is consuming more energy just to know more accurately when it's a good time to suspend to save energy? :) P.S.: On you reconsidering QTimer: the fact you might be using a different API won't change the base problem, which you will face anyway: having a precise timer implies consuming more resources and having more wakeups. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel