Bug 423161

Confirmed.

Just wanted to confirm this is still happening with the new Kickoff.

I’m annoyed by this especially because an ENTER keypress is disregarded during the “blink” period. If I type an app name very fast and press ENTER, nothing happens.

I’m interested in fixing this myself. I need to learn how to setup a proper environment to build, run and debug plasmashell. If I manage to do this, I will investigate it.

I found the probable culprit code, it's in krunner/src/runnermanager.cpp in the function scheduleMatchesChanged(). For every character typed, it emits matchesChanged() with an empty matches list before scheduling a second call to it with the matches actually filled.

I don't know why it did that, I will study the code deeper so I can fix it without causing any regression. Hopefully I will submit a MR in the next few days, so I'm assigning this bug report to myself.

I guess, this is "by design", you start a new query and that resets the list. However, Milou (the backend powering the standalone KRunner) has explicit code for this:

>    // We clear the model ourselves in the reset timer, ignore any empty matchset
>    if (matches.isEmpty() && m_resetTimer.isActive() && !m_hasMatches) {
>       return;
>  }

This avoids the flickering/teporary clearing of the list. Perhaps something similar could be implemented in Kickoff. Ideally, of course, Kickoff was ported to used the model from Milou.

Would be good to port it to use Milou indeed.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/82

Git commit a1d553a18515e02d42b2c1602549bedc958ef853 by Alexander Lohnau, on behalf of Eduardo Cruz.
Committed on 21/01/2022 at 18:29.
Pushed by alex into branch 'master'.

Fix flickering in Application Launcher for every character typed

This fixes the flickering that happened on the Application Launcher for every character typed.

Before:
![before](/uploads/cfd6dff218256a4de398deb9982e40df/before.gif)
After:
![after](/uploads/34a6aff7cc79dcb51f102c07573353ae/after.gif)

`RunnerManagerPrivate::scheduleMatchesChanged()` method forwards its events only once every 250ms. The issue was that it "wasted" the very first refresh cycle by forwarding the initially empty matches result set. It only forwarded meaningful results after 250ms, that's why the Application Launcher showed an empty list for 250ms for every character typed.

We are now stalling for the duration of the timeout (250ms) before starting to display results for a new query, so we kind of "ignore" the empty/near-empty result set (unless it actually hits the timeout with no more results coming in the meantime). This avoids refreshing the client with the initially empty (or near-empty) result set, so users won't see the empty list if more meaningful results come in the next 250ms (and they usually do come!).

I also saw that when the search job was done, the engine still waited for the running timeout until it displayed the last results it found. I changed that as well, so now we intercept the running timer, cancel it, and refresh immediately as soon as the job is done. So if the total query runs in less than 250ms, it won't even have to wait that: it will refresh only once (as intended), with the full result set, and as fast as possible.

As a result of all this, the application launcher feels much more responsive now, I believe it is a meaningful improvement in user experience.

Also benefits the standalone krunner since it will now respond faster than 250ms for simple quick queries.

M  +6    -0    autotests/CMakeLists.txt
A  +109  -0    autotests/runnermanagertest.cpp     [License: LGPL(v2.1+)]
M  +13   -0    autotests/testremoterunner.cpp
M  +6    -6    src/runnercontext.cpp
M  +30   -8    src/runnermanager.cpp

https://invent.kde.org/frameworks/krunner/commit/a1d553a18515e02d42b2c1602549bedc958ef853

This is so awesome! What an improvement!