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.
Details
- Reviewers
broulik ngraham - Group Reviewers
Frameworks - Commits
- R308:a07027cd4f22: Don't delay emission of matchesChanged indefinitely
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.
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?
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.
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.
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.