1) Hard to tell which window is selected with the keyboard Before Plasma 5.25, hovered or keyboard-selected windows in the Present Windows effect would become bigger (with animation), so it was easy to see where the focus is and where it transitions. Now the focused window is signalled with a narrow semi-transparent highlight, and it takes me much more time to figure out which window is focused. 2) Switching focus away from the search bar with the down arrow key is broken When the effect is triggered with a shortcut (Ctrl-F9 here), it's the search bar that is highlighted, and pressing the down arrow to choose the first window makes the highlight just vanish. Further arrow presses suggest it is probably the first window that is sort of focused, but there is no highlight to tell that, and pressing Enter does not actually select it. 3) Selecting the search bar with the keyboard is only possible once If I trigger the effect with my mouse, the search bar is not selected, and I can press Ctrl-F or the up arrow once to select it. But once I navigate away from it, I can no longer return to it without the mouse. If I trigger the effect with my keyboard, the search bar is focused from the start, and if I navigate away from it, there's no way back without the mouse. 4) Using the mouse and then the keyboard results in double focus If I use the "hot corner" to trigger the effect and leave the mouse hovering a window, then start using the arrow keys, I get 2 focus highlights which look identical. It is then hard to guess which of the two windows will get selected if I press Enter. SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Graphics Platform: X11 Graphics Processor: Mesa DRI Intel® UHD Graphics ADDITIONAL INFORMATION
> 1) Hard to tell which window is selected with the keyboard Agree. The highlight effect could be more obvious. Let's use this bug report to track the issue. > 2) Switching focus away from the search bar with the down arrow key is broken IIRC this is an X11-specific problem; it works fine for me on Wayland. Let's get a separate bug report for this. > 3) Selecting the search bar with the keyboard is only possible once Ctrl+F works for me on Wayland, but I can reproduce that the up arrow key won't focus it. Let's get a separate bug report for this. > 4) Using the mouse and then the keyboard results in double focus Can reproduce. Let's get a separate bug report for this.
Done: • https://bugs.kde.org/show_bug.cgi?id=455099 • https://bugs.kde.org/show_bug.cgi?id=455100 • https://bugs.kde.org/show_bug.cgi?id=455101
I assume that's the bug that Nate meant in the VDG group, thus suggesting that here: --- WindowHeap.qml 2022-06-16 00:33:35.627845270 +0200 +++ WindowHeapOrig.qml 2022-06-16 00:34:06.419713139 +0200 PlasmaCore.FrameSvgItem { anchors.fill: parent - anchors.margins: -PlasmaCore.Units.smallSpacing + anchors.margins: -PlasmaCore.Units.largeSpacing * 2 would lead to the attachment I'll upload in a sec which would be a lot easier to notice, it would also surround the window label. If people prefer a smaller one that doesn't surround the label, mediumSpacing would probably do
Created attachment 149765 [details] original size of the highlight
Created attachment 149766 [details] suggested bigger highlight
It doesn't have to be THAT huge as in your 2nd attachement but I do agree that it could be bigger.
Bugs 2 and 3 of this bug report (the issue with the keyboard) has now been fixed with this merge request (which will be merged in a few hours hopefully): https://invent.kde.org/plasma/kwin/-/merge_requests/2562
(In reply to Niklas Stephanblome from comment #6) > It doesn't have to be THAT huge as in your 2nd attachement but I do agree > that it could be bigger. The problem on an in-between is that it will most likely go right through the window title label. If we change it, I guess it either has to just not, or also include the window label (which imho is correct, since that label is part of what the user selected. If you e.g. select a file in a file manager, the file name is also part of the selection highlight). But maybe that whole label could be a bit repositioned.
> The problem on an in-between is that it will most likely go right through > the window title label. > If we change it, I guess it either has to just not, or also include the > window label Or we could leave the highlighting box as it is and instead make all unselected windows darker. Then it would be very noticable but still look good. What do you think?
(In reply to Niklas Stephanblome from comment #9) > > The problem on an in-between is that it will most likely go right through > > the window title label. > > If we change it, I guess it either has to just not, or also include the > > window label > Or we could leave the highlighting box as it is and instead make all > unselected windows darker. Then it would be very noticable but still look > good. What do you think? Hm, sorry but imho that would be the worse solution for mainly two reasons: 1) it would not be consistent, the highlight is sort of the same that we use in lists and it looks similar enough to non-QML qt app selections 2) The darker windows part was discussed in a different bug report about the desktop grid, where in the past the non-active ones were darker. People argumented, imo correctly so, that in an overview you should be able to easily "read" all elements, and making some elements darker works a bit against that. Note that my above patch is a quick and dirty solution, it could probably be fine-tuned, it could be done in a way so that there is still a margin between windows (which is what currently makes it look bad) and maybe the label could be re-thought and -positioned, then I think a bigger selection box would solve the problem and look nice.
Instead of this faint blue margin, I suggest a darker one. I’m against the bigger highlight box. Present Windows/Exposé has this appeal of a floating window overview. If you draw this big boxes, it will look less natural, more constrained and more like the Alt + Tab "Grid" effect option. Please don’t go this way. macOS 10.7 had this darker blue highlight in Mission Control: https://youtu.be/lTU7i_DtrdQ?t=282 Whis is still present today: https://youtu.be/uBYP5IdfoCo?t=89 I think, that’s the best way. Just paint the highlight darker.
Another possible alternative could be to just zoom in the window your mouse is over a bit like the old Present Windows effect has done. But without the darkening of the unfocused windows like before. This newer was especially pleasing in the old effect. But the slight zoom in combined with the faint blue could be enough. See here for this subtle zoom up of the window in the old Present Windows implementation: https://youtu.be/ysGu5fU6oFg?t=4 With a closer inspection of the current implementation, I see the highlight box does not only draw the outline but also does dye the window with this light blue highlight color. A darker tone thus would make the window darker and that’s not ideal when you are working with pictures/videos. I’m not that positive for this dyeing in general and would favorite a darker tone highlight outline without dyeing the actual window + a subtle zoom in like the old implementation did pretty well with its organic and playful touch.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2659
Git commit a0c8d4b24d816331f4865f167d09880620a61a19 by Nate Graham. Committed on 17/07/2022 at 02:55. Pushed by ngraham into branch 'master'. WindowHeap: expand size of highlight Currently, the highlight effect is not very visible because it only barely peeks out of the window thumbnail. We can make it bigger by making it peek out a little bit more, and also by including the window title and icon (when visible) within it. M +1 -1 src/effects/private/qml/WindowHeap.qml M +7 -2 src/effects/private/qml/WindowHeapDelegate.qml https://invent.kde.org/plasma/kwin/commit/a0c8d4b24d816331f4865f167d09880620a61a19