KDirWatch emitting dirty signal many times for one change

[Sébastien Laoût]

Le mer 14/04/2004 à 11:21, Daniel Martin Lambea a écrit :
>   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
> 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.

OK. But it must works.
If not it isn't really an interface if it works only with its owns :
it's a closed environment that we musn't leave one secund.

Le mer 14/04/2004 à 12:14, Josef Weidendorfer a écrit :
> 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).

OK.
So it do not do better but it's reliable.

Le mer 14/04/2004 à 11:57, Josef Weidendorfer a écrit :
> Binary compatibility: Adding virtual methods (like signals) to library classes 
> is not allowed in KDE 3.x...

Le mer 14/04/2004 à 12:06, David Faure a écrit : 
> A signal is not a virtual method!!
> You can add signals just fine.

Hum... What are this about ?
Why signals are allowed between +0.1 and not virtual methods ?
+0.x versions must keep binary compatibility ?
I wasn't know it :-)

Le mer 14/04/2004 à 12:21, Josef Weidendorfer a écrit : 
> Oops. I stand corrected. Then adding a signal fileRenamed() to KDirWatch 
> should be the way to go with KDE 3.3.

Cool.

Le mer 14/04/2004 à 12:42, Waldo Bastian a écrit :
> I don't see how you would be able to do that. KDirWatch has not enough 
> information for that, KDirLister might be able to, but not KDirWatch.

Erf !
But finnaly it is possible or not ??????????????????
Some peoples say no, some other say yes.

Le mer 14/04/2004 à 14:14, Josef Weidendorfer a écrit :
> KDirWatch is only an interface to deliver file change notifications from the 
> OS. Even if there currently is no implementation that can notify about 
> renames, it makes some sense that the interface can forward this kind of 
> notification.
> The FAM interface has rename notification, which could simply be forwarded by 
> KDirWatch. Of course it is quite possible that the FAM daemon on linux never 
> generates this kind of notification.
> Unfortunately, the DN_RENAME notification of DNOTIFY doesn't make much sense, 
> as the information is missing which file in a directory was renamed ;-(

Can I considere this anwer as a "yes it's doable" or as a "yes it's a doable
trick, half-reliable" ?

> I don't think that it's a 2.6 issue. The file system has to support it. I 
> don't know what's the status here. Does anybody know if XFS/ext2/ext3 on 
> current Suse/Fedora/Redhat already support them ??

Good question.
At the answer will depend my descision to cancel or not "file
abstraction" part of BasKet.
Even if in my mind it's a hack (meta-data are useless in my case : the
OS/deamon/environment mus work (togheter)) it's simple to implement...
Bu must be reliable in the majority of distributions/OSes.

> Don't know. But for sure an extended attribute can store the file name of some 
> XML file where all your meta information is stored or some index into a meta 
> information table inside of your app. The important thing here is that 
> renaming doesn't change the extended attribute.

Really good solution !

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

> Can't we use KFileMetaInfo to read available extended file attributes?

Hum... As I see it in the doc it's only for embedded meta-data *inside* the file.
Such as id3tags, WordProcessing informations (authors...), images size / compression...
All this is read by plug-ins.
But I never used this class : I can be wrong.
Oh ! I see :
ExtendedAttr : read filesystem based extended attributes if they are
               supported for the filesystem
OK. Good point !
I will look at distributions later if they support this (but hate this
solution : a note pad application cannot depend on this sort of
features).

Le mer 14/04/2004 à 15:25, Daniel Martin Lambea a écrit : 
>   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.
OK.
I've misinterpreted yours says.
Of cours we cannot recode all UNIX parts to graphic ones.

>   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)
I don't want network transparency : just that it work for local
filesystem.
But I cannot use DNOTIFY because I close my app to one OS and this isn't
requiered at all.

So this means to code an abstraction... in fact, to recode KDirWatch.

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

Yes : improve it.