Bug 454842

> 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