[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Broken konqueror (with fam)
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2002-02-19 17:20:13
[Download RAW message or body]

On Tuesday 19 February 2002 14:10, David Faure wrote:
> On Thursday 14 February 2002 14:59, Josef Weidendorfer wrote:
...
> > ... Or perhaps a semantic like "automatically watch all files in a
> > watched directory for changes" would be better?
>
> For Konqueror and KFile it would indeed be better.
> We want to automatically see that a file in the currently watched directory
> has grown. Having to add a file watch to every file in there would probably
> be far too much.
But exactly feature was the reason for the bug report in this thread:
Watch e.g. the log file grow, where the growing leads to more logging!

>
> > At the moment the additional info is simply ignored.
> > The same for creation/deletion of files in watched dirs. KDirWatch simply
> > says "dir dirty", and KDirLister has to check changes. But this
> > information is already available with FAM. Is this something to be
> > changed for KDE3.1? I'm not sure...
>
> Sounds difficult, if only FAM provides that information but not stat or
> dnotify.
The FAM damon usually uses /dev/imon. But if it's not available, it
in fact does simply STAT polling like we do, and actually watching ALL files
in a watched dir. Looking at debug output of fam, for KDE it stats usually
around 700 files :-)
I don't think that it's really too difficult, but then I think it's best to go 
for KDirWatch::addDir(QString path, bool watchFiles = false);
And as this is BIC, we have to add it before KDE 3 final, outputting
"feature not available" when requested with watchFiles=true.

>
> > But I really would love to see file notification working with KIO in a
> > general way, using KDirWatch in the IOSlave. But I have no idea how to do
> > this...
>
> !? A slave is a slave, it can't force something to happen (i.e. contact the
> app on its own when necessary). Code that triggers something upon receiving
> an event has to be in the app. What would this change anyway?
I once wrote a kio-plan (for the damon of the old motif groupware scheduler 
app "plan"), but there's no way to notify new meetings (inserted from remote 
users). It was still fine read-only, as it converted to VCAL and could be 
used with korganizer. 
Another usage: The SAMBA KIO can't forward file adds/deletions...
But I think I'm dreaming...


-- 
--
Josef Weidendorfer


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]