Unconsistent KDirNotify API

David Faure faure at kde.org
Tue Sep 28 21:00:17 BST 2004

On Tuesday 28 September 2004 21:45, Sébastien Laoût [temporar] wrote:
> Le mar 28/09/2004 à 21:38, David Faure a écrit :
> > It is intended
> Ah. this is ennoying.
> So I basically should store all file names and compare the list each
> time directory changed, to know what are the new files. Hum :-/

If you only care about local files, use KDirWatch, and you'll have the info you want.
Otherwise, use KDirLister, and what you say (comparing to see which are the new files)
is exactly what KDirLister does for you.

> > , because the list of added files wouldn't be enough information
> > anyway (you want to know their size, mimetype, etc.).
> > That was the design decision (that one needs to do a listDir()
> Ah? A listDir() should be done just for one new file!

Sure - how else do you know all about that file? OK you could stat it,
but if there are 10 new files, 10 stats could be slower than one listDir,
due to the communication overhead.

> >  anyway, so
> > the list of files isn't useful), but maybe you're right, that's somewhat 
> > konqueror-specific (well, KDirLister specific, more generally).
> > 
> > Maybe this should be redone in KDE 4 to have both FilesAdded( list ) and 
> > DirectoryChanged( dir ) or so - with the explicit mention that only one
> > should be emitted, depending on the available information
> > (no need to do things twice in e.g. KDirLister).
> > FilesAdded currently means DirectoryChanged, basically.
> Is QT allow to know if slots are connected to signals?
> I will look at that.
> Then if nobody is connected, no need to make the computations (KURL
> creations...).
> Oh... The are ASSYNC. Hum. Forgive that, then.

This is about *DCOP* signals, not about Qt signals.

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