Josef.Weidendorfer at gmx.de
Wed Sep 25 13:40:05 BST 2002
On Wednesday 25 September 2002 00:59, Main user of this system wrote:
> > - the "recursive" and "watchFiles" option has to be dynamic, otherwise
> > their is no use of implementing this in KDirWatch; your approach is
> > static and only looks for files existing when adding the watch.
> > E.g. if a file is created in directory of a watch entry with option
> > "watchFiles", it should automatically be watched, too. And of course
> > deleted with the original entry. Same holds for the "recursive" flag.
> I understand. I'll see if i can implement this the right way. I assume
> (without looking at the code, so i could be wrong) that it has to the new
> directory entry (file or dir) to itself before it emits one of the 3
> signals ? (BTW the docu is wrong imo, it talks about 3 additional signals
> in the addDir docu that i cant find anywhere in the class).
The signal number was changed 1 or 2 days before KDE 3 API freeze :-)
Connecting to the signals itself is perhaps the best idea - no fiddling with
low level details of the 3 notification methods (STAT/FAM/DNOTIFY).
Regarding BC: You can change KDirWatchPrivate to your liking.
But keep in mind that KDirWatchPrivate is global for the app, but
there can be multiple KDirWatch instances watching the same dirs/files.
This is needed for FAM (only 1 connection to the FAM server) and DNOTIFY
(one "global" signal handler!).
The best would be to remember the "originating" entry (base for recursive
added entries), together with a "dependents" list in the originating entry, I
> > BTW: Main use of the "recursive" flag would be in KDED, where recursive
> > dirs are watched. Every time KDED detects a change, it deletes ALL
> > watches and creates them again. This is much overhead for nothing. In
> > KDirWatch, this could be done VERY efficient...
> Ouch, that is indeed very inefficient. I can also use such a beast for
> Kompare when one compares 2 directories :) I dont want to add every
> file/directory manually (even files/dirs that currently dont have changes
> should be watched if something changes in them).
There is some strange exclusion of some files in KDED when going recursive.
Does somebody know why ???
> I will try to mail something to you this weekend if time permits :)
More information about the kde-core-devel