Bug 455783

*** Bug 455790 has been marked as a duplicate of this bug. ***

Also note that "the search bar" is not clean up when the effect is launched. 
The previous search (and filtering) would be still active but perhaps that's a second bug report?

(In reply to Carlos Colorado from comment #2)
> Also note that "the search bar" is not clean up when the effect is launched. 
> The previous search (and filtering) would be still active but perhaps that's
> a second bug report?

Yes, see https://bugs.kde.org/show_bug.cgi?id=455786

I reported a couple of bugs since the new effect has plenty, but it's prefered to have one report per problem.
The problem you mention is known and should be fixed whenever that other merge request gets merged and lands in a release, if you need a temporary workaround, see the bug report linked above, it's a one-liner.

Git commit 66d127879461aed2e6c6312d52219502a6354f71 by Nate Graham, on behalf of Marco Martin.
Committed on 24/06/2022 at 15:56.
Pushed by ngraham into branch 'master'.

Internal tracking for quick effect item focus

focus used to be always forced to the root item of the view in the
"active screen" (which behavior is configurable between mouse poosition
and screen of active window)
now set focus to that particular view only if nothing is focused, also when
the user explicitly sets focus to an item in another view
remove focus to the old one so the item properly focused would be there
Related: bug 455807, bug 455633

M  +5    -0    src/libkwineffects/kwinoffscreenquickview.cpp
M  +2    -0    src/libkwineffects/kwinoffscreenquickview.h
M  +35   -4    src/libkwineffects/kwinquickeffect.cpp
M  +5    -0    src/libkwineffects/kwinquickeffect.h

https://invent.kde.org/plasma/kwin/commit/66d127879461aed2e6c6312d52219502a6354f71

Git commit ea5bc72dc27562b99b81f2b3ddb855468353896e by Nate Graham, on behalf of Marco Martin.
Committed on 24/06/2022 at 15:56.
Pushed by ngraham into branch 'Plasma/5.25'.

Internal tracking for quick effect item focus

focus used to be always forced to the root item of the view in the
"active screen" (which behavior is configurable between mouse poosition
and screen of active window)
now set focus to that particular view only if nothing is focused, also when
the user explicitly sets focus to an item in another view
remove focus to the old one so the item properly focused would be there
Related: bug 455807, bug 455633


(cherry picked from commit 66d127879461aed2e6c6312d52219502a6354f71)

M  +5    -0    src/libkwineffects/kwinoffscreenquickview.cpp
M  +2    -0    src/libkwineffects/kwinoffscreenquickview.h
M  +35   -4    src/libkwineffects/kwinquickeffect.cpp
M  +5    -0    src/libkwineffects/kwinquickeffect.h

https://invent.kde.org/plasma/kwin/commit/ea5bc72dc27562b99b81f2b3ddb855468353896e

Quick question, is this supposed to be fixed in 5.25.2? 

If so: unfortunately doesn't work, I can still only select items on the current screen with the keyboard, and not ones on my secondary screen.

(In reply to Christian (Fuchs) from comment #6)
> Quick question, is this supposed to be fixed in 5.25.2? 
> 
> If so: unfortunately doesn't work, I can still only select items on the
> current screen with the keyboard, and not ones on my secondary screen.

Can confirm, the issue is still present.

With the new unified behavior between "Overview" and "Present Windows", this issue is likely related to bug #456331

*** Bug 456330 has been marked as a duplicate of this bug. ***

*** Bug 456331 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2680

Git commit 027ca22908a6f020c101ddd7e8f512fe0186655d by Marco Martin.
Committed on 02/08/2022 at 15:59.
Pushed by mart into branch 'master'.

When an arrow key is not accepted look for adjacent views

When no qml items manage the arrow key event, the root item will manage it looking to give focus to a view in the given direction derived from the arrow key

M  +34   -0    src/effects/desktopgrid/qml/main.qml
M  +26   -0    src/effects/overview/qml/ScreenView.qml
M  +1    -1    src/effects/private/qml/WindowHeapDelegate.qml
M  +24   -0    src/effects/windowview/qml/main.qml
M  +83   -13   src/libkwineffects/kwinquickeffect.cpp
M  +11   -1    src/libkwineffects/kwinquickeffect.h
M  +1    -0    src/scripting/CMakeLists.txt
M  +2    -0    src/scripting/scripting.cpp

https://invent.kde.org/plasma/kwin/commit/027ca22908a6f020c101ddd7e8f512fe0186655d

*** Bug 457434 has been marked as a duplicate of this bug. ***

There is still one behavior left from this regression.

1. There is no active cursor by default, cursor has to be invoked manually,  If there is only one window visible after filtering the enter key does nothing without manually invoking the window selector. 

2. Inconsistent window selector dismissal when widening or narrowing the window filter.
If you match more windows with your filter, the cursor remains active. 
If you match less windows  with your filter, the cursor gets dismissed. 

3. There is some strange behavior when activating the window selector, when there are filtered windows where you have to press multiple times the arrows 2 or 3 to actually show up, perhaps this depends on the number of screens I have 3 screens and  when having only 1 window present on my display #3 it takes one or two arrow presses for the cursor to active). 

Depending on how the feature is implemented, fixing the issue might be as simple as having the cursor always active, even when the effect is just invoked. Needing to invoke the cursor just messes with the flow of the effect, worst if the behavior is inconsistent.

The change on behavior of this effect took my window management out of the "muscle memory" territory and more into the "think about it" territory, took me a while to put my finger on what was wrong about it.

Please submit new bug reports for those issues, thanks.