2015-11-19 17:17 GMT+01:00 René J.V. <rjvber...@gmail.com>: > 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.
Again - this is not against IOKit or what Apple does, but your usage of QTimer in your code. RRs are meant for constructive feedback, and everyone here is striving to keep a positive attitude and explain the reasons why such a comment has been made (speaking of which, thanks Boudhayan for the insightful message). I really hope you will reconsider this and accept the feedback, it would be really sad to see MacPorts differ from upstream. As Martin said before, we're here to help and keep code consistent, there's no interest in giving you this kind of feedback just for the sake of it. KIdleTime is a framework with a purpose and some requirements, if you want to build something which can cover time-critical applications, it definitely does not belong there. > > 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
