fvogt added a comment.
In D21607#474771 <https://phabricator.kde.org/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. REPOSITORY R308 KRunner REVISION DETAIL https://phabricator.kde.org/D21607 To: fvogt, #frameworks, broulik Cc: bruns, kde-frameworks-devel, LeGast00n, michaelh, ngraham
