KDirWatch emitting dirty signal many times for one change

David Faure faure at kde.org
Thu Apr 15 07:45:20 BST 2004


On Thursday 15 April 2004 02:51, Josef Weidendorfer wrote:
> But if KDirWatch is low-level and only for local files and mounts, we should 
> only use it in the KIO file-protocol implementation, provide a notification 
> mechanism in the KIO interface, and KDirNotify should be hidden below KIO, 
> too. Then for KDE applications, there would be only one, network-enabled 
> mechanism for change notifications (I suppose that currently, each use of 
> KDirWatch in network-enabled KDE apps is a special-case handling for the file 
> protocol).
True.

> The way (for KDE4?) would be that a ListJob can be potentially indefinitly 
> long, signalling file changes/creations/deletings/renamings while it's 
> running (Perhaps there should be an additional signal that normal directory 
> listing has finished). Aborting this job would mean that autonotification is 
> stopped.
Yes, sounds good.

> The current KIO implementation does most of the things by routing to KIO 
> slaves, but we could put change notifications for the file-protocol directly 
> below the KIO functions. This way, the KIO slave protocol isn't touched at 
> all.
I don't think adding new things to the slave protocol is a problem, anyway.

> > KDirWatch is the layer that's just above the filesystem, KDirNotify is
> > the (KIO/DCOP only) notification of an operation that happened
> > in KDE (which is the only way to refresh FTP views properly, etc.)
> > The fact that it acts as a workaround for missing rename() notification
> > from KDirWatch is only an added bonus; the main point is that it's network
> > transparent.
> 
> Does this mean that I can use the KDirNotify DCOP interface to signal file 
> changes from a KIO slave? Or is KDirNotify only triggered by GUI actions?

Interesting idea. I thought (some time ago) that slaves can't use DCOP,
but apparently this isn't true... So this should work I think...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).





More information about the kde-core-devel mailing list