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

List:       kde-core-devel
Subject:    Re: KDirWatch bug and the analysis. Help is welcome!
From:       David Faure <faure () kde ! org>
Date:       2013-08-02 11:11:32
Message-ID: 3487543.iF47YQXuB5 () asterix
[Download RAW message or body]


On Thursday 01 August 2013 21:24:19 Rolf Eike Beer wrote:
> David Faure wrote:
> > On Thursday 01 August 2013 01:30:08 Mark wrote:
> > > However, we have been given the power of inotify which gives more
> > > detailed
> > > signals and lets us know which files have been created/added/modified
> > > which
> > > we should be used imho.
> > 
> > OK. First let's imagine that it's not a hidden file. Say you create "foo"
> > file (from the command line) in a directory currently shown in dolphin.
> > When using inotify, we could get a "foo was created" signal, but then
> > what?
> > KDirLister is going to need more details anyway (size, mimetype, date,
> > icon, etc.). To get that, it re-lists the directory. Don't say it could
> > just KIO::stat the new file, it becomes very slow if many files get
> > created/modified, and it creates much more complex code paths in
> > kdirlister
> > which is already complex (it would also need to handle deletion
> > separately). Instead we have a single reaction to "something changed in
> > this directory"> 
> > : re-list it and update it to show the changes (after basically diff'ing
> > 
> > the new listing and the old listing).
> 
> Handling delete should be much simpler than adds as you do not need to
> lookup any new information, so avoiding the whole directory scan on delete
> sounds like a good idea to me in any case, no?

Yep.

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

["signature.asc" (application/pgp-signature)]

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