KDirWatch emitting dirty signal many times for one change

[Daniel Martin Lambea]

>>> 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).

  Well, I was trying to clarify that your sentence "I agree we must be
able to have a 100% graphic environment" would not mean that KDE will
offer every piece of UNIX functionality under a graphical flag. There
will be lots of things KDE can offer, and there will be some others that
won't be so easy to do. What I wanted to mean is that of course you will
encounter difficulties in facing some tasks, specially those which
involve deep system features.

  If the solution to your questions is to use DNOTIFY, so be it. If the
issue is that DNOTIFY is unable to work well in network-oriented
filesystems, or in heterogeneous filesystems, or even in a rename
operation, then the first step might be to archieve that in DNOTIFY, and
then use DNOTIFY in your KDE app. (I say "DNOTIFY" in no special manner;
one can use FAM, if preferred)

  As an example, I am working on a dynamic DNS registration app for KDE.
It is almost sure that a single computer will have more than one user,
and therefore, the app should run on *every* user session. Another
problem is that maybe nobody opens their session, and therefore the app
won't run in time. My solution is not to tweak KDE, but to extend a
dynamic DNS daemon in order to make my app to be able to talk to it. The
next step? To finish my app.

> 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.

  I see. The first I think of is to make KDirWatch to support rename
notifications.  :-m

  Regards,
    Daniel M. Lambea