[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-11-19 9:36:53
Message-ID: 3576495.MFBHBDj2qG () portia ! local
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]