Bug 423161 - Search results blink when updating
Summary: Search results blink when updating
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: 5.20.90
Platform: Manjaro Linux
: NOR minor
Target Milestone: 1.0
Assignee: Eduardo
Keywords: usability
Depends on:
Reported: 2020-06-18 14:17 UTC by Claudius Ellsel
Modified: 2022-01-21 19:07 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25


Note You need to log in before you can comment on or make changes to this bug.
Description Claudius Ellsel 2020-06-18 14:17:49 UTC
Why searching for an application the search results refresh. During that they disappear for some short time and reappear leading to some blinking experience.

1. Press META
2. Type a letter
3. Type another letter

After typing a followup letter the search results refresh (disappearing and reappearing refreshed)

Have the list of results refresh without completely blanking the list and having items reappear, but more smoothly.

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.0
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0
Kernel Version: 5.6.17-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Xeon® CPU E3-1225 v3 @ 3.20GHz
Memory: 3.8 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics P4600/P4700

When using a certain time for the pauses between the letters no blinking actually happens. Most times I don't type in that constant intervals of pauses,  so that is not really helpful, but might give some hint.
Comment 1 Nate Graham 2020-06-19 17:55:12 UTC
Comment 2 Claudius Ellsel 2021-01-25 17:02:04 UTC
Just wanted to confirm this is still happening with the new Kickoff.
Comment 3 Eduardo 2021-12-14 05:54:53 UTC
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.
Comment 4 Eduardo 2021-12-23 13:35:57 UTC
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.
Comment 5 Kai Uwe Broulik 2021-12-23 13:45:51 UTC
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.
Comment 6 Nate Graham 2021-12-23 14:40:09 UTC
Would be good to port it to use Milou indeed.
Comment 7 Bug Janitor Service 2021-12-24 19:43:11 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/82
Comment 8 Alexander Lohnau 2022-01-21 18:29:14 UTC
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.


`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

Comment 9 Nate Graham 2022-01-21 19:07:26 UTC
This is so awesome! What an improvement!