On Thursday November 19 2015 08:10:08 Martin Graesslin wrote: > I want to apologize for saying that. Please be aware that this was only > intended as a description of code (yes I also call code written by myself > idiotic and worse things) and not against you.
Apology accepted, but please realise for the future that calling code names written by someone who has clearly shown he believes in his way of doing things will inevitably be taken personnally. > I hope you don't fork, because I think that would be bad. Not because you > move Apologies if my use of the word "mirror" suggested that. I'm not intending to fork, but I do intend to provide my patch through the MacPorts mechanism, in the form that takes into account almost all feedback given, and with documentation updated to reflect those changes and what the framework really does and the potential side-effects its underlying implementation might have. (It doesn't guarantee that the "msec" value in the timeoutReached signal will be exactly the requested timeout, for instance, because it can only guarantee what the platform backend can make true). > the code else where, but because the issues pointed out would be unresolved > giving users of your code a bad framework and thus harming both your users as > well as the frameworks project for distributing bad code. The problem of > polling is real. Please accept this feedback. 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. R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
