On Thursday November 19 2015 15:21:10 Dario Freddi wrote: > * KIdleTime strives to be as lightweight as possible. This is something >which came from the old approach used in KDE3/4 powermanagement which was ... >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
That kind of application simply doesn't make sense on operating systems that already have their own, built-in power management... OTOH, I wouldn't be amazed if it is non-trivial to guarantee good and reliable timing accuracy on an OS like Linux: that would fit in with the experience I have with its use in time-critical applications (where it always required realtime extensions to the kernel). But I continue the think that a simple framework like this can very well attempt to provide the best accuracy/cost compromise that the host allows, esp. if that doesn't mean adding crazy complexity. As it happens, OS X returns the "idle time" in *nano* seconds; do not think for a second (pun intended) that it would do that if the underlying measurement didn't have that kind of accuracy. I think that makes it safe to say that my current implementation indeed provides just short of a 1ms accuracy, with a CoarseTimer and an adaptive polling interval that spends most of the timeout duration waiting for the timer to fire. It's quite possible that's enough, and that there will never be any reason (demand) to export the interval control I drafted. But consider this: KF5 frameworks are young (despite the almost crazy progression of the release number, which for me is a telltale sign of immaturity). They are also hardly (nor have they been) used beyond Linux, and in practice not at all on OS X. Who knows what uses any framework might be considered for that wasn't really part of its original mission statement? If that's always going to elicit a rejecting attitude, I'll be better off going back to making the minimum modifications required to make things work for MacPorts, and only request inclusion if it turns out maintaining those changes requires too much continuous effort. As to use over a remote, non-X11 connection: applications should not attempt to determine idle time in that case. They shouldn't receive return values that suggest 0 idle time, they should receive an error that tells them they're out of bounds. If Qt provided a way to raise an error to the user (and force the app to exit) without provoking a crash (abort), I'd use that, but I'm not aware of any such facility. As it is, the OS X implementation will probably signal the actual idle time of whomever is logged in locally ... R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
