KIO::ListJob::entries emits twice for folders with 100+ entries. Why?

[David Faure]

On Wednesday 14 November 2012 22:18:08 Albert Astals Cid wrote:
> El Dimecres, 14 de novembre de 2012, a les 17:32:35, Mark va escriure:
> > Hi,
> > 
> > I'm playing with KIO::listDir() and the signals to get the directory
> > content and i've hit a strange "issue". Apparently when a folder has
> > more than 100 entries the entries signal [1] will be emitted twice.
> > 1 with 100 entries
> > 1 with all entries

All? That would lead to duplication, I strongly doubt that this is the case, 
it would confuse KDirLister very much.
Which ioslave is this about? kio_file, apparently?
 
> > Also, this only seems to happen if i add:
> > job->addMetaData("details", "0");
> > See the full code example [2] that also contains the above line.

`kioclient ls /dir` can also be used to test KIO::listDir from the command-
line, although adding details=0 has to be patched in.
Tried that, no bug.

kioclient ls /k/testbug174144 | sort | wc -l
kioclient ls /k/testbug174144 | sort | uniq | wc -l
both show the same result, 502.

Now trying your testcase...

 (C++) dumpEntries() 
-------------- BEGIN DUMPING ENTRIES -------------- 
99 
-------------- END DUMPING ENTRIES -------------- 
(C++) dumpEntries() 
-------------- BEGIN DUMPING ENTRIES -------------- 
401 
-------------- END DUMPING ENTRIES -------------- 

Total 500. No duplicates.

> > On IRC kde__pepo suggested that the first emit might be so that the
> > app using it has at least some results while waiting for the rest.

Yes entries can be emitted multiple times, but not with duplicates.

> > Is there an option to disable this behavior? In my case i don't want
> > nor need the extra signal and i "was" depending on that signal to
> > properly fill my model. However, since that might be emitted twice it
> > screwed up my logic and my personal workaround is to rather just
> > depend on the results signal (which i can't find in the API docs).
> 
> You mean "result" instead of "results", right? I see it documented in the
> KJob class, problaby you want the finished signal, (if it is job being done
> that you are waiting for)

No no no. In 99.99% of the cases, result() is the signal you want.
I thought I made that clear in the last revision of the api documentation :(

result() -> to trigger application logic that should run when the job is done
finished() -> to hide progress dialogs, or to delete the job by hand

The difference: result() is not emitted by kill(Silently).

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