kdirwatch vs qfilesystemwatcher

Marc Espie espie at nerim.net
Tue Mar 6 11:45:35 GMT 2007


On Sat, Mar 03, 2007 at 02:22:59AM +0100, Andreas Pakulat wrote:
> On 02.03.07 23:30:39, Marc Espie wrote:
> > While updating the qt4 port for OpenBSD, I noticed the new kqueue support
> > and activated it.
> > 
> > Comparing it for kdirwatch, it is currently grossly inefficient on OpenBSD.
> > 
> > I was wondering, what's the difference between kdirwatch and 
> > qfilesystemwatcher ? In newer qt4, it just looks like qfilesystemwatcher
> > is doing mostly the same thing in a more efficient way across platforms.
> 
> Well, KDirWatch doesn't stop watching files/dirs after they are removed,
> it only emits 1 signal for dirs or files regardless wether the file/dir
> changed or is removed..
> 
> I hope that either of the two gets heavily extended, for example
> stopping KDirWatch to watch a specific file (currently it only allows to
> stop for a dir), watching a dir should emit signals when  a file is
> created or removed with the filename/dirname not just a dirty signal and
> the app has to somehow figure out which file/dir was added/removed.

Well, this doesn't help me much.

So this is saying that the base kde class is more extensive than what
qt does, but still this is not enough ?

Okay, here's the issue, currently on some `normal' unix systems, KDirWatch
is responsible for a huge number of stat() calls.  On BSD systems, we've
had kqueue for a while, and Qt4 is finally taking advantage of that.

Before I embark on having a look at KDirWatch and tweaking it to use kqueue
(or to leverage the base Qt4 class more), I'd like some strong signal that
this is going to be useful. Like, if the KDirWatch published interface
changes/gets expanded a lot, I will have to restart the work from
scratch, which I'd rather avoid...




More information about the kde-core-devel mailing list