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

List:       kde-core-devel
Subject:    Re: [PATCH] KDirLister: emitChanges, deleteItems
From:       Michael Brade <brade () kde ! org>
Date:       2002-03-07 10:23:28
[Download RAW message or body]

On Thursday 07 March 2002 11:05, David Faure wrote:
> On Thursday 07 March 2002 10:48, Michael Brade wrote:
> > On Thursday 07 March 2002 00:41, David Faure wrote:
> > > A remark about your questions in the comments for FilesChanged.
> >
> > Whoops... forgot to remove them.
>
> You did well, this way we can discuss them ;)
Ok, so there's one answer missing: where's the difference between 
KURL::directory() and KURL::path()? I had a short look at KURL's code but I 
only understood the code for directory() and I think the docu is not the best 
it could have ;)

> > > It was first making a list of directories to update, using
> > > KURL::directory() on each url being passed (in the file items), and was
> > > then calling updateDirectory() on those. That doesn't sound like the
> > > best solution though, the point is that we know which files changed, so
> > > maybe a refreshItems() or whatever it's called now would be better.
> > > This call isn't about files added or deleted, only about files changed
> > > internally (e.g. change the icon of a .desktop file to test this).
> >
> > But then why didn't we do this in the old lister as well? Strange...
> > you're right, if the file changed and it's already in itemsInUse, then an
> > item->refresh() updates the entry already, updateDirectory should have no
> > chance to revert this (same for the old lister).
>
> Ok, that's the normal case (item already listed) and it should indeed be no
> problem to do a refresh() (and an emit refreshItems)
Fine.

> > Ahh, I see... I think there's a problem, that wasn't even fixed in the
> > old one: if you start to open a directory with the job running in the
> > background, picking up a file but not emitting it yet, and then change
> > the file. A FilesChanged signal comes in, searches for the item, does not
> > find it and thus does nothing. The "old" item will be emitted then. Same
> > for updates: if you create a new file, the update picks it up and then
> > the file is changed, nothing happens. So it's just about new files
> > changed immediately after creation I guess.
>
> Ok. What about looking for the item in the "items already created but not
> yet emitted" buffer then? If it can be updated there, then the correct
> version of the item will be emitted at the end of the listing (openURL or
> update, doesn't matter). Then it's not even needed to emit refreshItems in
> such a case.
Hmm, right, I guess you mean the buffer in KDirListerCache::jobs. But I meant 
that the job itself picks up the item but does not emit entries() yet. 
Perhaps a very rare case we don't have to deal with?

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3.0: Konquering the Desktops


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