[Nepomuk] Bugs, Patches and Scripts. - StrigiService & KInotify
Sebastian Trüg
trueg at kde.org
Tue May 11 07:45:51 CEST 2010
Hi Vishesh,
very nice. Please commit. Except if the blockSignals does not work. Does
it work now?
Only a minor hint: in general I would recommend to use
Q_FOREACH( const QString& s, strings )
since that avoids a copy of the string. Now in case of strings this is
no big deal (shared) but it makes sense to remember it for other types.
Cheers,
Sebastian
On 05/11/2010 01:08 AM, Vishesh Handa wrote:
> Hi Sebastian
>
> How to block signals:
> 1. Use QObject::blockSignals()
>
>
> Didn't work! :-( I've seen the disconnect/reconnect approach being used
> successfully as well. There must be something special about this case.
> I'll check it out tom.
>
> * There is no real need to optimize the folder list in the filewatch
> service. StrigiServiceConfig already does that before giving the list to
> the IndexScheduler
>
>
> I thought it's better to optimize it once before saving it rather than
> optimize it every time while loading. Anyway, I've removed the
> optimization code. It's now redundant.
>
>
> * I think we need a better name than "restart". Maybe "ignore last
> config change" or something like that.
>
>
> I've changed it to "ignore changes". Is that okay?
>
>
> * Any chance the config handling in IndexScheduler could be moved to
> StrigiServiceConfig? Just so config handling is restricted to the
> one class.
>
>
> Done.
>
>
> * Now for the only critical use case: imagine filewatch changes the
> config, then the kcm changes the folders, and only then strigi gets to
> the config. I am not sure if that can even happen but if so strigi would
> ignore the new config. But I suppose this is very unlikely to happen or
> even impossible.
>
>
> The probability of this happening is very low. However I've edited KCM
> to make sure it doesn't occur.
>
> I've modified the patch to remove auto adding of sub folders to indexed
> list as that is what everyone wanted. (I don't!)
>
> - Vishesh Handa
>
More information about the Nepomuk
mailing list