[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