Don't delay emission of matchesChanged indefinitely
ClosedPublic

Authored by fvogt on Jun 5 2019, 3:23 PM.

Details

Summary

Currently the signal is only emitted if there was no change to the matches in
the last 100ms. Especially during krunner startup and early result collection,
this is unlikely to happen though, so make sure that the signal is emitted
at least once every ~500ms.

Test Plan

Sometimes results only appeared after a noticable delay, now this
delay is much shorter.

Diff Detail

Repository
R308 KRunner
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
fvogt created this revision.Jun 5 2019, 3:23 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptJun 5 2019, 3:23 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
fvogt requested review of this revision.Jun 5 2019, 3:23 PM
bruns added a subscriber: bruns.Jun 5 2019, 3:55 PM

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

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

achieve essentially the same?

fvogt added a comment.EditedJun 5 2019, 4:34 PM

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?

fvogt added a comment.Jun 5 2019, 4:45 PM

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.

fvogt added a comment.Jun 6 2019, 10:06 AM

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.

fvogt updated this revision to Diff 59252.Jun 6 2019, 10:07 AM

New algorithm with no delay if not necessary.

ngraham added a subscriber: ngraham.Jun 6 2019, 5:35 PM

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

fvogt added a comment.Jun 18 2019, 5:00 PM

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.

ngraham accepted this revision.Wed, Jun 19, 7:27 AM

I tried it and it works fine for me. Note that the AppStream runner's behavior has improved as of 0.12.7 since it now correctly returns no results instead of all results when it doesn't get a match.

This revision is now accepted and ready to land.Wed, Jun 19, 7:27 AM
This revision was automatically updated to reflect the committed changes.