[PATCH] update interval bugfix

[Aaron J. Seigo]

On Sunday 20 January 2008, Chani wrote:
> > this could also be done a bit better by making setCachedUpdated() set
> > dirty to true. this would achieve the same thing and be even more
> > straight forward, as well as removing the need for the extra boolean as
> > well.
>
> I thought about that, but then how does it get reliably un-set again? I
> think I needed a way to tell the difference between something being really
> dirty and just faking it.

my concern is that DataEngine::checkForUpdate() now only triggers when dirty 
== true.

so if a SignalRelay could update, then the main DataContainer is asked for an 
update which is pre-empted by the update timeout, and thereby not update the 
DataContainer at all.

moreover, this can prevent previously queued signals from being emitted as 
well.

at the same time ... reading the code more thoroughly here, the requestUpdate 
signal only comes from SignalRelays, never the source itself, so i can see 
why this works as it is now. and it does have the advantage of not triggering 
the main source unless necessary ......

ok, i'm fine with the extra bool; the connection between SignalRelays and 
requestUpdate() should be covered, though, in the setCachedUpdate method.

> > after calling setCachedUpdated() in DataEngine::internalUpdateSource, a
> > call to d->queueUpdate() is also needed just in case we don't get any
> > other valid updates.
>
> err.... hrm. I'm not so sure about this.
> let me go reread the code after tomorrow's exam. I don't remember this
> patch clearly enough.

reading it again, it's indeed not strictly necessary since setCachedUpdate 
causes immediate emmission of the dataUpdated signal versus queuing it in 
SignalRelay. again, documentation in setCachedUpdate would be immensely 
useful here.

perhaps even a line in DataEngine::internalUpdateSource about why it isn't 
needed would be good. note that the updateQueue issue is noted in the TODO 
comment in there itself. so maybe remove that and replace with an explanation 
of why we don't need an update queue'd.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080120/e86ab092/attachment-0001.pgp