https://bugs.kde.org/show_bug.cgi?id=423161

Alexander Lohnau <alexander.loh...@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Latest Commit|                            |https://invent.kde.org/fram
                   |                            |eworks/krunner/commit/a1d55
                   |                            |3a18515e02d42b2c1602549bedc
                   |                            |958ef853
         Resolution|---                         |FIXED

--- Comment #8 from Alexander Lohnau <alexander.loh...@gmx.de> ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to