This would emit the signal more often, but wouldn't

if (!matchChangeTimer.isActive())
  matchChangeTimer.start(100)

achieve essentially the same?

In D21607#474763, @bruns wrote:

This would emit the signal more often, but wouldn't

if (!matchChangeTimer.isActive())
  matchChangeTimer.start(100)

achieve essentially the same?

That would do it even more often.

I'm thinking about doing it completely differently now though, with a 0 latency case (untested):

if(lastMatchChangeSignalled.hasExpired(250)) {
    matchChangeTimer.stop();
    emit q->matchesChanged(context.matches());
} else {
    matchChangeTimer.start(250 - lastMatchChangeSignalled.elapsed());
}

What do you think?

In D21607#474771, @fvogt wrote:

I'm thinking about doing it completely differently now though, with a 0 latency case (untested):

if(lastMatchChangeSignalled.hasExpired(250)) {
    matchChangeTimer.stop();
    emit q->matchesChanged(context.matches());
} else {
    matchChangeTimer.start(250 - lastMatchChangeSignalled.elapsed());
}

Just tried this and it's not too bad, but a noticable change in behaviour. As results are shown basically immediately once they're available, it's now visible how the entries are filled.

So for the stable branches I'd like to keep the current version of the diff with a latency of [100,599] while for master something like the above with a latency of [0,500] can be tried.

In D21607#474772, @fvogt wrote:

So for the stable branches I'd like to keep the current version of the diff with a latency of [100,599] while for master something like the above with a latency of [0,500] can be tried.

And I just now realize that I'm stupid and mixed this up with milou. krunner is a framework so there is no stable branch...

I'll update the diff to the [0,250] case.

I think it's quite fine to have the entries jump around a little bit. To me it makes KRunner feel faster to have it start displaying results immediately and then refining them milliseconds later. +1

Before I land this, I'd like if someone other than me tries krunner with this patch applied and judges the result with several runners. The difference is very noticable with the appstream runner as it does not batch results.