The new application switcher (since 5.25) reachable with Meta-W or app-group like with Meta-F7 does only somewhat reacto on keyboard input. Depending on what you press (arrow keys, or tab/shift-tab) you'll get an indicator around the windows selected (small blueish emphasis) I would suggest that tab/shift tab should be working right from the start when activating the overview to switch between the input field and the windows, the cursor keys should be active only inside the input field (as expected for text) or, when windows are selected in the overview, to quickly move the selection up/down/left/right. Currently this is more a lottery if and when the keyboard works as intended (here again: please think of using the gui with the keyboard as well, mouse is obviously working, but when i start an overview with the keyboard, then i insist on operating the appearing gui by keyboard as well. Don't force users to switch input gear)
Are you on X11? It works properly for me on Wayland.
yes, X11 another find (when keyboard input is working) I have a 2 screen setup. Navigation with cursor-keys on screen1 works ok, but how do you change screens? I cannot access the window-thumbnails on screen2 (besides clicking on screen2 with the mouse) Wouldn't 'tab' be a good idea (in analogy to krusader?) And: how do you switch virtual desktops? (without using the mouse)
for the virt. desktop 'preview' and switching: i would suggest Alt+ some letter of the virt. desktop-name? (like menu-shortcuts)
Great news everyone, I fixed this issue completely and the keyboard navigation now works like with the presentwindows effect from 5.24 and before. The merge request is currently pending and will (I hope) be merged very soon. Here is is: https://invent.kde.org/plasma/kwin/-/merge_requests/2562 It makes sure that as soon as you start typing anything, one window is ALWAYS highlighted with the green box around it and you can change the selection with the arrow keys, even while typing in the search box. This exactly resembles the keyboard navigation with the old presentwindows effect.
that's great news! one more thing: the highlighting around the virt. desktop view (when navigating by keyboard) is a bit faint, esp. on a 4K monitor. Any chance to configure this somewhere? (same is true for the window-highlighting, but here i would say ... visible enough for me)
(In reply to slartibart70 from comment #5) > that's great news! > > one more thing: > the highlighting around the virt. desktop view (when navigating by keyboard) > is a bit faint, esp. on a 4K monitor. > Any chance to configure this somewhere? > (same is true for the window-highlighting, but here i would say ... visible > enough for me) Hi, I'm not sure what virtualdesktop-view you are referring to. Do you know the default keyboard combination by any chance?
Meta-W the new overview, with - here - 4 virtual desktops on top of the screen, below the search-input field the rest on gray background with windows miniatures of currently open programs (i took an image with the phone, spectacle is not active in this view) You see, if you happen to have a blue background, then the emphasis/highlight in blue is very faint
Created attachment 150057 [details] overview
do you have multiple screens enabled?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2572
Git commit 6838b1132fad8b32c26409fd46b2e49803684dd6 by Nate Graham, on behalf of Niklas Stephanblom. Committed on 23/06/2022 at 17:13. Pushed by ngraham into branch 'master'. Windowview: Fix broken keyboard navigation while filtering After the 5.25 update, one could not see which window was highlighted until one manually unfocused the SearchField and then pressed any key to refresh the WindowHeap. Also, the searchbar would (most of the time) "absorb" the arrow keys so one had to also unfocus it to really be able to select windows with they keyboard. With this change, there is always one window highlighted while filtering using the search box. Also, one can select another window with the arrow keys without manually unfocusing the searchbox. This heavily improves the keyboard functionality in this effect that got lost with the 5.25 update of presentwindows to windowview and resolves complaints about the keyboard navigation being buggy. Related: bug 455764, bug 455099, bug 455586, bug 455753 FIXED-IN: 5.25.2 M +6 -2 src/effects/windowview/qml/main.qml M +3 -0 src/effects/windowview/windowvieweffect.cpp https://invent.kde.org/plasma/kwin/commit/6838b1132fad8b32c26409fd46b2e49803684dd6
Git commit dcc77bfa8fbca8032047fbbb5ab65382293488ac by Nate Graham, on behalf of Niklas Stephanblom. Committed on 23/06/2022 at 17:16. Pushed by ngraham into branch 'Plasma/5.25'. Windowview: Fix broken keyboard navigation while filtering After the 5.25 update, one could not see which window was highlighted until one manually unfocused the SearchField and then pressed any key to refresh the WindowHeap. Also, the searchbar would (most of the time) "absorb" the arrow keys so one had to also unfocus it to really be able to select windows with they keyboard. With this change, there is always one window highlighted while filtering using the search box. Also, one can select another window with the arrow keys without manually unfocusing the searchbox. This heavily improves the keyboard functionality in this effect that got lost with the 5.25 update of presentwindows to windowview and resolves complaints about the keyboard navigation being buggy. Related: bug 455764, bug 455099, bug 455586, bug 455753 FIXED-IN: 5.25.2 (cherry picked from commit 6838b1132fad8b32c26409fd46b2e49803684dd6) M +6 -2 src/effects/windowview/qml/main.qml M +3 -0 src/effects/windowview/windowvieweffect.cpp https://invent.kde.org/plasma/kwin/commit/dcc77bfa8fbca8032047fbbb5ab65382293488ac
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 455783 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 455783 (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
On a multi-screen setup keyboard navigation is still restricted to the active screen only, even with Plasma updated to 5.25.2. If I want to navigate to window thumbnails in another screen I can't use the keyboard and have to use a pointer device.
That's Bug 455783, which is a separate issue.