[Nepomuk] Bugs, Patches and Scripts. - StrigiService & KInotify

[Vishesh Handa]

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 -

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.

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)

Possible fixes (in order of preference) -
1. Somebody fixes KDirWatch
2. We use a separate config file to store the "config changed" variable
3. We a use a QTimer::singleShot(...) to unblock the signals after a certain
interval. (Not fool proof. I've tried it)

- Vishesh Handa


On Tue, May 11, 2010 at 11:15 AM, Sebastian Trüg <trueg at kde.org> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100520/f4c2d2d2/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strigi.diff
Type: text/x-patch
Size: 8498 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100520/f4c2d2d2/attachment-0003.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strigi2.diff
Type: text/x-patch
Size: 11382 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100520/f4c2d2d2/attachment-0004.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KDirWatchPatch.diff
Type: text/x-patch
Size: 419 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100520/f4c2d2d2/attachment-0005.diff