KDirWatch emitting dirty signal many times for one change

[Michael Brade]

On Wednesday 14 April 2004 14:14, Josef Weidendorfer wrote:
> On Wednesday 14 April 2004 12:42, Waldo Bastian wrote:
> > > Oops. I stand corrected. Then adding a signal fileRenamed() to
> > > KDirWatch should be the way to go with KDE 3.3.
> >
> > I don't see how you would be able to do that. KDirWatch has not enough
> > information for that, KDirLister might be able to, but not KDirWatch.
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.)

> 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 
really don't want to create possible loops. Furthermore KDirWatch should stay 
stand-alone with regards to KDirLister since the latter one is the add-on in 
case someone needs not only names but KFileItems.

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience