[Development] QSystemAlignedTimer to QtCore

[lars.knoll at nokia.com]

On 11/21/11 11:39 PM, "ext lorn.potter at nokia.com" <lorn.potter at nokia.com>
wrote:

>
>On 21/11/2011, at 9:51 PM, ext shane.kearns at accenture.com wrote:
>
>> It should be used to extend the QTimer API.
>> Where the system doesn't support this kind of timer, then the in
>>process solution as in Thiago's blog should be used.
>> 
>> Should there be a preferred interval?
>> For some use cases, the timer is allowed to be late but not early (e.g.
>>supervisory timeouts) in which case preferred == minimum
>> Whereas for other use cases, the timer is allowed to be late or early
>
>Preferred interval is (maximum + minimum) / 2. Where there is no max
>value given, then min is preferred, but timeout is not guaranteed to any
>one specific time with this timer.
>
>> 
>> Out of interest, which platforms support this kind of timer? (other
>>than symbian which isn't supported by Qt5)
>> 
>
>Besides symbian, only harmattan/meego that I know of.
>A working generic backend should/would need to be supplied, IMHO,
>otherwise this is useless.

Agree, but it shouldn't be difficult to do a generic backend based on the
system clock. So if you want to wakeup every 5 minutes, we'll always do
that at a defined clock time for all apps. We could simply say when the
system clock shows a round multiple of 5 minutes.

The generic fallback might not be ideal, as all apps wake up at exactly
the same time and not one after the other, but would IMO be good enough
for most use cases.

In general is makes a lot of sense to merge this functionality into
QTimer, even if it won't be perfect on some platforms.

>
>> Finally, when this functionality is in QtCore, then the QSystemInfo API
>>should be replaced with a shim over the QtCore implementation.
>> I.E. implement a backend that uses the QTimer API and remove any OS
>>specific backends, and mark the API as deprecated.
>
>I disagree. That would mean QtSystemInfo would no longer work on Qt 4.
>
>
>>> Now I'm thinking of move it to QtCore, and preferably merge it into
>>> QTimer. If so, we probably need to add some interface to specify the
>>> precision, other than simply tell the type as in [1].
>>> Any thoughts?
>>> 
>>> 
>
>Originally, there were two methods.
>something like:
>
>startTimer(minimum, maximum);
>startTimer(preferred, timerWindow);
>
>where preferred was most likely the average of max and min, and
>timerWindow was the length of time allowable to fire (max - min). I
>preferred the second method, as it seemed more natural to me, but was
>dropped as it seemed too confusing to some.
>
>
>I can email you more details if needed.
>
>
>>> [1] http://codereview.qt-project.org/#change,657
>>> 
>
>Personally, I would not tack it on to that change, but it's own change
>that depends on that one.

Yes, that sounds right. So can someone clean up Thiago's patch (fix the
few comments in there and add proper docs) and then get it in as a first
step?

Cheers,
Lars