I know I was supposed to commit this a long time back, but I just can't get it to work! After some amount of debugging I realized my code was fine, and the problem is that KDirWatch is buggy (I don't have the bandwidth to fix it! Do I report it at bugs.kde?). There are 2 problems with KDirWatch -<br>
<br>1. It's slow - I block all the signals, and write to the config file, and then unblock the signals. A little while after that the dirty() signal is emitted! I decided to hack through this issue by ... look at strigi2.diff -> StrigiService::slotConfigChanged(). And that's when I discovered the second bug.<br>
<br>2. It doesn't always fire the dirty signal - Yes. I know. Weird! (If you feel inclined to test it, apply the KDirWatchPatch to kdelibs/kdecore)<br><br>Possible fixes (in order of preference) - <br>1. Somebody fixes KDirWatch<br>
2. We use a separate config file to store the "config changed" variable<br>3. We a use a QTimer::singleShot(...) to unblock the signals after a certain interval. (Not fool proof. I've tried it)<br><br>- Vishesh Handa<br>
<br><br><div class="gmail_quote">On Tue, May 11, 2010 at 11:15 AM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org">trueg@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Vishesh,<br>
<br>
very nice. Please commit. Except if the blockSignals does not work. Does<br>
it work now?<br>
<br>
Only a minor hint: in general I would recommend to use<br>
<br>
Q_FOREACH( const QString& s, strings )<br>
<br>
since that avoids a copy of the string. Now in case of strings this is<br>
no big deal (shared) but it makes sense to remember it for other types.<br>
<br>
Cheers,<br>
<font color="#888888">Sebastian<br>
</font><div><div></div><div class="h5"><br>
On 05/11/2010 01:08 AM, Vishesh Handa wrote:<br>
> Hi Sebastian<br>
><br>
> How to block signals:<br>
> 1. Use QObject::blockSignals()<br>
><br>
><br>
> Didn't work! :-( I've seen the disconnect/reconnect approach being used<br>
> successfully as well. There must be something special about this case.<br>
> I'll check it out tom.<br>
><br>
> * There is no real need to optimize the folder list in the filewatch<br>
> service. StrigiServiceConfig already does that before giving the list to<br>
> the IndexScheduler<br>
><br>
><br>
> I thought it's better to optimize it once before saving it rather than<br>
> optimize it every time while loading. Anyway, I've removed the<br>
> optimization code. It's now redundant.<br>
><br>
><br>
> * I think we need a better name than "restart". Maybe "ignore last<br>
> config change" or something like that.<br>
><br>
><br>
> I've changed it to "ignore changes". Is that okay?<br>
><br>
><br>
> * Any chance the config handling in IndexScheduler could be moved to<br>
> StrigiServiceConfig? Just so config handling is restricted to the<br>
> one class.<br>
><br>
><br>
> Done.<br>
><br>
><br>
> * Now for the only critical use case: imagine filewatch changes the<br>
> config, then the kcm changes the folders, and only then strigi gets to<br>
> the config. I am not sure if that can even happen but if so strigi would<br>
> ignore the new config. But I suppose this is very unlikely to happen or<br>
> even impossible.<br>
><br>
><br>
> The probability of this happening is very low. However I've edited KCM<br>
> to make sure it doesn't occur.<br>
><br>
> I've modified the patch to remove auto adding of sub folders to indexed<br>
> list as that is what everyone wanted. (I don't!)<br>
><br>
> - Vishesh Handa<br>
><br>
</div></div></blockquote></div><br>