[Nepomuk] [PATCH] Strigiservice Initial Run timing bug.

[Vishesh Handa]

On Wed, Apr 21, 2010 at 3:04 PM, Sebastian Trüg <trueg at kde.org> wrote:

> Hi Vishesh,
>
> very nice. One question:
> Why do you time the paused state instead of the indexing? Isn't it
> easier to understand if you time the indexing and when paused add the
> elapsed time to m_initialIndexTime?
>
>
Actually. I'm timing both the indexed and the paused time (
m_initialIndexTime & m_pausedIndexTime ). When it transitions to a paused
state, the paused timer is started and when it resume, the paused time is
subtracted from the m_initialIndexTime. This would be so much easier if
QTime provided pause() and resume() functions.

I could not start the m_initialIndexTime timer, and add the indexed time
when it transitions to a paused state or finishes. Both approaches seem
fairly intuitive to me. Your call. It's just a 2-min job changing it.


> And I just realized another bug in the service: the eventmonitor does
> not get informed when the indexing is resumed by another party (for
> example manually by the user). In that case the timing is wrong again.
>
>
Yup. You're right. We'll have to connect the indexscheduler's
indexingSuspended signal to a new slot, which could call the appropriate
pauseIndexing() or resumeIndexing() function. This seems to be slightly
counter intuitive as pauseIndexing() also tells the index scheduler to pause
its indexing, but that shouldn't be a problem.

I'll take care of it.

- Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100421/60b7528a/attachment.htm