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

[Mark]

On Thu, Nov 15, 2012 at 11:02 AM, David Faure <faure at kde.org> wrote:
> 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
>

Hi David,

My bad, the second signal is only emitting the remainder of whatever
comes after the first signal.
However, i still have the question as to why it happens at all?

The two signal stuff for entries only seems to occur when i set:
job->addMetaData("details", "0");

If i just comment that line out i have just 1 signal from entries. Why
is it working like that? I would expect it to behave the same with or
without addMetaData("details", "0") set. I personally would just like
to get rid of the first signal since in my case all entries are feeded
to a model anyway.

Cheers,
Mark