KDirWatch emitting dirty signal many times for one change

[Josef Weidendorfer]

On Wednesday 14 April 2004 16:23, Michael Brade wrote:
> No, KDirLister has no information at all regarding renames (yet). If
> KDirWatch doesn't tell if a file was renamed KDirLister has no idea about
> it. And I don't know if it's worth making KDirLister much slower by
> checking the created KFileItems for meta data and comparing that to
> previously deleted items (ugh, where should we store the "deleted" items?
> Should we really compare every new item with every deleted item? For how
> long to store them? nono, I rather quit hacking KDE before implementing
> that.)

Please stay ;-)
If there is a place for a heuristic to detect renams from delete/create 
notifications, then this is KDirWatch itself for sure. But you are right, 
it's quite difficult. And not very reliable. So perhaps it's not worth it.

> > Another question: Could KDirWatch catch rename notifications from
> > KDirLister?
>
> *lol* No, not at all. KDirLister is using KDirWatch to get the file change
> notifications. (Well, apart from the DCOP signal FileRenamed or so). So we

Ah, I meant this signal, not KDirLister. I think that KDirWatch in fact should 
be the responsible to forward file changes which are done by GUI actions like 
this Rename DCOP signal. And that is reliable. The same for future signals of 
this kind from D-BUS.

Josef