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

List:       kde-panel-devel
Subject:    Re: [Panel-devel] dataengines and timing revisited
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-08-30 19:24:23
Message-ID: 200708301324.23432.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 30 August 2007, Alex Merry wrote:
> On Thursday 30 Aug 2007, Aaron J. Seigo wrote:
> > remaining caveats: the clock has an interesting problem where it
> > really wants to pin the ticks to clock ticks, especially for the
> > minutes-only ... i have yet to figure out how to arrange that.
> > without it, it is possible for the ticks to drift dramatically so
> > that the time is up 59s out. maybe it's just me, but that would suck
> > =) if someone provides a clock that just shows the hour, that could
> > be even worse. then again, perhaps the clock, as a special case, just
> > continues to manage its own update ticks.
>
> My first thought would be for the data source to update internally every
> half-second.

this sucks for power management, unfortunately. it is indeed a simple and 
straight forward means of accomplishing the goal for the clock, but 
slaughters batteries =)

much better is to wake up once every minute (for anything over a minute) and 
do a quick check for timer drift and, if necessary, correct. 

> When the shortest requested update frequency every minute or hour, you
> could even possibly do some complicated optimisations where it, for
> example, put a timer (ie: slept) for 58s, then checked the time every
> half-second until it changed and then push out the update and put the
> timer back on.

this is similar to the wake-up-and-check-for-drift and probably better if 
greater accuracy is demanded. however, ime with the clock in kde3, waking up 
once per minute and checking for drift worked much more accurately than 
needed at means only waking up once perminute versus the 5 in this suggestion 
=)

however, this might work nicely (as in "more naturally") with the proposed 
dataengine mechanism and turn out to be the winner in any case =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


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