423161 2020-06-18 14:17:49 +0000 Search results blink when updating 2022-01-21 19:07:26 +0000 1 1 4 Plasma plasmashell Application Launcher (Kickoff) widget 5.20.90 Manjaro Linux RESOLVED FIXED usability NOR minor 1.0 1 claudius.ellsel eduardo.cruz eduardo.cruz kde.podagric kde nate plasma-bugs-null qydwhotmail https://invent.kde.org/frameworks/krunner/commit/a1d553a18515e02d42b2c1602549bedc958ef853 5.25 0 oldest_to_newest 1938110 0 claudius.ellsel 2020-06-18 14:17:49 +0000 SUMMARY Why searching for an application the search results refresh. During that they disappear for some short time and reappear leading to some blinking experience. STEPS TO REPRODUCE 1. Press META 2. Type a letter 3. Type another letter OBSERVED RESULT After typing a followup letter the search results refresh (disappearing and reappearing refreshed) EXPECTED RESULT Have the list of results refresh without completely blanking the list and having items reappear, but more smoothly. SOFTWARE/OS VERSIONS 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 ADDITIONAL INFORMATION 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. 1938511 1 nate 2020-06-19 17:55:12 +0000 Confirmed. 1997561 2 claudius.ellsel 2021-01-25 17:02:04 +0000 Just wanted to confirm this is still happening with the new Kickoff. 2085203 3 eduardo.cruz 2021-12-14 05:54:53 +0000 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. 2087737 4 eduardo.cruz 2021-12-23 13:35:57 +0000 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. 2087739 5 kde 2021-12-23 13:45:51 +0000 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. 2087743 6 nate 2021-12-23 14:40:09 +0000 Would be good to port it to use Milou indeed. 2088010 7 bug-janitor 2021-12-24 19:43:11 +0000 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/82 2096574 8 alexander.lohnau 2022-01-21 18:29:14 +0000 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:  After:  `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 2096593 9 nate 2022-01-21 19:07:26 +0000 This is so awesome! What an improvement!