KDirWatch emitting dirty signal many times for one change

[Josef Weidendorfer]

On Wednesday 14 April 2004 11:21, Daniel Martin Lambea wrote:
> >> We're developing a GUI environment. IMHO it's fine to say that some
> >> features don't work well when people start messing around with the
> >> console.
> >
> > 1/ OK I agree we must be able to have a 100% graphic environment.
> > BUT, we are on UNIX. And we also must provide command line
> > equivalents...
> > With your reasonment we go back on the MS way : 100% GUI... or do
> > nothing.
>
>   Tell me if I'm wrong, but as I understood, I think David wanted to say
> that KDE is exactly what it is: a GUI. We don't try to build a complete
> system, just a user interface to the real system. With that in mind, we

But what's the issue of a GUI which promises to give you an up-to-date view to 
the filesystem when it can not hold this promise? In fact, KDE tries hard to 
give you this up-to-date view by using KDirWatch, even if this perhaps means 
1% CPU activity all the time on a slow machine (with STAT).

> see the limits to our possibilities. One of the limits is that we cannot
> control all the access to the filesystem, system-wide. This is a task
> for a lower layer.

But this lower layer already exists (e.g. DNOTIFY), and
KDirWatch is the interface to this lower layer. So KDE apps can react on file 
changes. This thread is about the problem that KDirWatch currently doesn't 
have support for rename notifications, and one workaround for this is to use 
KDirLister. But its limitation (only renames which originate from GUI rename 
actions) is not useful in all use cases. For KDesktop, it's obviously enough.

Josef